[Bug c++/20208] [4.0/4.1 Regression] No array-to-pointer decay happens for template functions
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20208
[Bug c++/20381] [4.0/4.1 Regression] ICE in build_ptrmemfunc, at cp/typeck.c:5702
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-03-09 07:45 --- Kriang -- This is probably caused by your recent OFFSET_REF changes; would you please investigate? -- Mark -- What|Removed |Added CC||lerdsuwa at users dot ||sourceforge dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20381
[Bug c++/20142] [3.3 regression] implicit assignment operator with multi-dimensional array is broken
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-03-09 07:42 --- Fixed in GCC 3.4.4. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Summary|[3.3/3.4/4.0/4.1 regression]|[3.3 regression] implicit |implicit assignment operator|assignment operator with |with multi-dimensional array|multi-dimensional array is |is broken |broken http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20142
[Bug c++/20142] [3.3/3.4/4.0/4.1 regression] implicit assignment operator with multi-dimensional array is broken
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-09 07:41 --- Subject: Bug 20142 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-03-09 07:41:00 Modified files: gcc/testsuite : ChangeLog gcc/testsuite/g++.dg/init: array18.C Log message: PR c++/20142 * g++.dg/init/array18.C: Add dg-do run marker. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5129&r2=1.5130 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/init/array18.C.diff?cvsroot=gcc&r1=1.2&r2=1.3 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20142
[Bug c++/20142] [3.3/3.4/4.0/4.1 regression] implicit assignment operator with multi-dimensional array is broken
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-09 07:39 --- Subject: Bug 20142 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_4-branch Changes by: [EMAIL PROTECTED] 2005-03-09 07:39:48 Added files: gcc/testsuite/g++.dg/init: array18a.C Log message: PR c++/20142 * g++.dg/init/array18.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/init/array18a.C.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=NONE&r2=1.1.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20142
[Bug c++/20142] [3.3/3.4/4.0/4.1 regression] implicit assignment operator with multi-dimensional array is broken
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-09 07:39 --- Subject: Bug 20142 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_4-branch Changes by: [EMAIL PROTECTED] 2005-03-09 07:39:35 Modified files: gcc/cp : init.c ChangeLog gcc/testsuite : ChangeLog Log message: PR c++/20142 * init.c (build_vec_init): When determining whether or not the element type has an asignment operator, look through all array dimensions. PR c++/20142 * g++.dg/init/array18.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/init.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.356.2.16&r2=1.356.2.17 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.3892.2.204&r2=1.3892.2.205 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.3389.2.369&r2=1.3389.2.370 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20142
[Bug c++/20142] [3.3/3.4/4.0/4.1 regression] implicit assignment operator with multi-dimensional array is broken
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-09 07:32 --- Subject: Bug 20142 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-03-09 07:32:31 Modified files: gcc/cp : init.c ChangeLog gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/init: array18.C Log message: PR c++/20142 * init.c (build_vec_init): When determining whether or not the element type has an asignment operator, look through all array dimensions. PR c++/20142 * g++.dg/init/array18.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/init.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.412.2.1&r2=1.412.2.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.4648.2.5&r2=1.4648.2.6 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5084.2.26&r2=1.5084.2.27 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/init/array18.C.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.2.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20142
[Bug c++/20142] [3.3/3.4/4.0/4.1 regression] implicit assignment operator with multi-dimensional array is broken
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-09 07:28 --- Subject: Bug 20142 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-03-09 07:28:12 Modified files: gcc/testsuite : ChangeLog gcc/cp : ChangeLog cp-tree.h decl.c init.c name-lookup.c typeck.c Added files: gcc/testsuite/g++.dg/init: array18.C Log message: PR c++/20142 * cp-tree.h (target_type): Remove. * decl.c (layout_var_decl): Remove #if 0'd code. (cp_finish_decl): Remove dead code. * init.c (build_vec_init): When determining whether or not the element type has an asignment operator, look through all array dimensions. * typeck.c (target_type): Remove. PR c++/20142 * g++.dg/init/array18.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5128&r2=1.5129 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/init/array18.C.diff?cvsroot=gcc&r1=1.1&r2=1.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4654&r2=1.4655 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/cp-tree.h.diff?cvsroot=gcc&r1=1.1107&r2=1.1108 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/decl.c.diff?cvsroot=gcc&r1=1.1374&r2=1.1375 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/init.c.diff?cvsroot=gcc&r1=1.413&r2=1.414 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/name-lookup.c.diff?cvsroot=gcc&r1=1.110&r2=1.111 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/typeck.c.diff?cvsroot=gcc&r1=1.617&r2=1.618 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20142
[Bug tree-optimization/18527] cannot determine number of iterations for loops with <=
--- Additional Comments From irar at il dot ibm dot com 2005-03-09 06:56 --- New testcase added: vect-3.f90 (in autovect branch for now). If this PR is solved, testcase vect-3.f90 will be vectorized. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18527
[Bug c++/20208] [4.0/4.1 Regression] No array-to-pointer decay happens for template functions
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-09 06:43 --- x86-pc-linux-gnu, and powerpc-darwin. Both fail the same way. On x86_64-pc-linux-gnu with 4.0.0 20050121, I get the ICE also. Note this is at -O1 or above. -- What|Removed |Added GCC target triplet||i686-pc-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20208
[Bug c++/20350] [4.0/4.1 Regression] extern template and struct initializer and specification for a static variable
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-03-09 06:42 --- This is not valid code. The "extern" specifier in the template specialization is not permitted by ISO C++, nor is the G++ "extern template" extension. -- What|Removed |Added Keywords|ice-on-valid-code |ice-on-invalid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20350
[Bug c++/20208] [4.0/4.1 Regression] No array-to-pointer decay happens for template functions
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-03-09 06:37 --- On what target does this fail? It does not fail for me on x86_64-unknown-linux-gnu, and neither does PR 2892. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20208
[Bug c++/20142] [3.3/3.4/4.0/4.1 regression] implicit assignment operator with multi-dimensional array is broken
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20142
[Bug libgcj/20391] New: gcj-dbtool shows incorrect error message if JAR and DSO are switched on the command line
If the JAR and DSO are switched on the command line to "gcj-dbtool -a", it shows an incorrect error message: ~/src/tmp > gcj-dbtool -a foo.db foo.so foo.jar error: could not update foo.db: java.lang.NullPointerException -- Summary: gcj-dbtool shows incorrect error message if JAR and DSO are switched on the command line Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rmathew at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20391
[Bug c++/17256] [3.3/3.4/4.0/4.1 Regression] undefined but used static or inline functions should be diagnosed
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-09 04:49 --- This broke again on the mainline (before the branch of 4.0.0 and even before 3.5.0 was changed to 4.0.0). -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Known to fail|3.3.4 3.4.0 |3.3.4 3.4.0 4.0.0 4.1.0 Known to work|2.95.3 4.0.0|2.95.3 Summary|[3.3/3.4 Regression]|[3.3/3.4/4.0/4.1 Regression] |undefined but used static or|undefined but used static or |inline functions should be |inline functions should be |diagnosed |diagnosed http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17256
[Bug c++/14777] [3.4/4.0/4.1 Regression] typedef doesn't fully expose base class type
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-09 04:45 --- (In reply to comment #5) > The first example has been fixed in 3.4.1. > > The second example is an accepts-invalid and may not be a regression. It is a regression from 3.3.3 and 3.2.3. -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Known to fail|3.4.0 4.0.0 |3.4.0 4.0.0 2.95.3 4.1.0 Summary|typedef doesn't fully expose|[3.4/4.0/4.1 Regression] |base class type |typedef doesn't fully expose ||base class type Target Milestone|--- |3.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14777
[Bug java/15525] suggestion to enable cast elimination
-- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Last reconfirmed|2004-11-06 19:02:10 |2005-03-09 04:38:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15525
[Bug c++/19199] [3.3/3.4/4.0/4.1 Regression] Wrong warning about returning a reference to a temporary
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-03-09
04:11 ---
Subject: Re: [3.3/3.4/4.0/4.1 Regression] Wrong warning about returning a
reference to a temporary
On Mar 8, 2005, Roger Sayle <[EMAIL PROTECTED]> wrote:
> On 8 Mar 2005, Alexandre Oliva wrote:
>>
>> * fold-const.c (non_lvalue): Split tests into...
>> (maybe_lvalue_p): New function.
>> (fold_ternary): Use it to avoid turning a COND_EXPR lvalue into
>> a MIN_EXPR rvalue.
> This version is Ok for mainline, and currently open release branches.
Unfortunately, the problem in g++.oliva/expr2.C resurfaced, because,
as it turns out, the transformation (I != J ? I : J) => I yields an
lvalue as required, but not the *correct* lvalue in all cases. I
tried what you'd suggested on IRC (testing whether the thing is an
lvalue after the fact), but that obviously failed in this case as
well.
So I figured a better approach would be to perform lvalue tests to
fold_cond_expr_with_comparison(), where we can avoid specific
inappropriate transformations while still trying other alternatives.
While at that, I figured we could use pedantic_lvalues to avoid
refraining from applying optimizations just because it looks like the
cond-expr might be an lvalue, even though the language requires it not
to be.
This is currently bootstrapping on x86_64-linux-gnu. Ok to install if
bootstrap completes and regtesting passes?
Index: gcc/ChangeLog
from Alexandre Oliva <[EMAIL PROTECTED]>
PR c++/19199
* fold-const.c (non_lvalue): Split tests into...
(maybe_lvalue_p): New function.
(fold_cond_expr_with_comparison): Preserve lvalue-ness.
Index: gcc/fold-const.c
===
RCS file: /cvs/gcc/gcc/gcc/fold-const.c,v
retrieving revision 1.535
diff -u -p -r1.535 fold-const.c
--- gcc/fold-const.c 7 Mar 2005 21:24:21 - 1.535
+++ gcc/fold-const.c 9 Mar 2005 03:59:18 -
@@ -2005,16 +2005,12 @@ fold_convert (tree type, tree arg)
}
}
-/* Return an expr equal to X but certainly not valid as an lvalue. */
+/* Return false if expr can be assumed to not be an lvalue, true
+ otherwise. */
-tree
-non_lvalue (tree x)
+static bool
+maybe_lvalue_p (tree x)
{
- /* While we are in GIMPLE, NON_LVALUE_EXPR doesn't mean anything to
- us. */
- if (in_gimple_form)
-return x;
-
/* We only need to wrap lvalue tree codes. */
switch (TREE_CODE (x))
{
@@ -2054,8 +2050,24 @@ non_lvalue (tree x)
/* Assume the worst for front-end tree codes. */
if ((int)TREE_CODE (x) >= NUM_TREE_CODES)
break;
-return x;
+return false;
}
+
+ return true;
+}
+
+/* Return an expr equal to X but certainly not valid as an lvalue. */
+
+tree
+non_lvalue (tree x)
+{
+ /* While we are in GIMPLE, NON_LVALUE_EXPR doesn't mean anything to
+ us. */
+ if (in_gimple_form)
+return x;
+
+ if (! maybe_lvalue_p (x))
+return x;
return build1 (NON_LVALUE_EXPR, TREE_TYPE (x), x);
}
@@ -4162,7 +4174,15 @@ fold_cond_expr_with_comparison (tree typ
tree arg00 = TREE_OPERAND (arg0, 0);
tree arg01 = TREE_OPERAND (arg0, 1);
tree arg1_type = TREE_TYPE (arg1);
- tree tem;
+ tree tem = NULL;
+ /* If the COND_EXPR can possibly be an lvalue, we don't want to
+ perform transformations that return a simplified result that will
+ be recognized as lvalue, but that will not match the expected
+ result. We may still return other expressions that would be
+ incorrect, but those are going to be rvalues, and the caller is
+ supposed to discard them. */
+ bool lvalue = !pedantic_lvalues
+&& maybe_lvalue_p (arg1) && maybe_lvalue_p (arg2);
STRIP_NOPS (arg1);
STRIP_NOPS (arg2);
@@ -4196,10 +4216,12 @@ fold_cond_expr_with_comparison (tree typ
case EQ_EXPR:
case UNEQ_EXPR:
tem = fold_convert (arg1_type, arg1);
- return pedantic_non_lvalue (fold_convert (type, negate_expr (tem)));
+ tem = pedantic_non_lvalue (fold_convert (type, negate_expr (tem)));
+ break;
case NE_EXPR:
case LTGT_EXPR:
- return pedantic_non_lvalue (fold_convert (type, arg1));
+ tem = pedantic_non_lvalue (fold_convert (type, arg1));
+ break;
case UNGE_EXPR:
case UNGT_EXPR:
if (flag_trapping_math)
@@ -4211,7 +4233,8 @@ fold_cond_expr_with_comparison (tree typ
arg1 = fold_convert (lang_hooks.types.signed_type
(TREE_TYPE (arg1)), arg1);
tem = fold (build1 (ABS_EXPR, TREE_TYPE (arg1), arg1));
- return pedantic_non_lvalue (fold_convert (type, tem));
+ tem = pedantic_non_lvalue (fold_convert (type, tem));
+ break;
case UNLE_EXPR:
case UNLT_EXPR:
if (flag_trapping_math)
@@ -4222,12 +4245,18 @@ fold_cond_expr_with_comparison (tree typ
arg1 = fold_convert (lang_hooks.types.signed_type
(TREE_TYPE (arg1)), arg1);
tem = fold (bu
[Bug target/20126] [3.3/3.4/4.0/4.1 Regression] Inlined memcmp makes one argument null on entry
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-03-09 04:02 --- Subject: Re: [PR target/20126, RFC] loop DEST_ADDR biv replacement may fail On Mar 8, 2005, Jakub Jelinek <[EMAIL PROTECTED]> wrote: > Unfortunately, it seems to break ada bootstrap on at least x86-64 and i386: Odd... It surely completed bootstrap for me with default build flags. Hmm... FORTIFY_SOURCE? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20126
[Bug inline-asm/20382] internal compiler error with bogus asm output constraint
--- Additional Comments From sailors3 at comcast dot net 2005-03-09 02:48
---
Subject: RE: internal compiler error with bogus asm output constraint
Where can I find some documentation on using this extended asm format? I
have read all the GNU docs on it and can not understand how to use it.
Thanks,
Dave
-Original Message-
From: falk at debian dot org [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 08, 2005 6:25 AM
To: [EMAIL PROTECTED]
Subject: [Bug inline-asm/20382] internal compiler error with bogus asm
output constraint
--- Additional Comments From falk at debian dot org 2005-03-08 14:25
---
Confirmed. This is triggered by a bogus argument for an output constraint.
Not a regression.
void f() {
__asm__ ("" : "=r" ("r5"), "+r" ("r5"));
}
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|middle-end |inline-asm
Ever Confirmed||1
GCC build triplet|3.3.1-macraigor1|
GCC host triplet|3.4.0 |
GCC target triplet|3.3.1 |
Keywords||ice-on-invalid-code
Known to fail||2.95.4 3.2.3 3.3.5 3.4.3
||4.1.0
Summary|internal compiler error in |internal compiler error
with
|emit_move_insn, at |bogus asm output constraint
|expr.c:2809 |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20382
--- You are receiving this mail because: ---
You reported the bug, or are watching the reporter.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20382
[Bug target/20126] [3.3/3.4/4.0/4.1 Regression] Inlined memcmp makes one argument null on entry
--- Additional Comments From jakub at redhat dot com 2005-03-09 01:47
---
Subject: Re: [PR target/20126, RFC] loop DEST_ADDR biv replacement may fail
On Mon, Mar 07, 2005 at 06:56:19PM -0300, Alexandre Oliva wrote:
> loop attempts to eliminate a biv represented by a pseudo in favor of a
> giv represented by (plus (reg) (const_int -1)). Unfortunately, the
> biv pseudo appears in an insn that doesn't accept anything but a
> register, so validate_change fails and the error goes unnoticed.
>
> The patch below fixes the problem and passed bootstrap on
> x86_64-linux-gnu (testing still pending), but I'm not very comfortable
> with the use of location for the assignment. Is this a safe change?
> Any loop experts around willing to take a second look on this? Thanks
> in advance,
Unfortunately, it seems to break ada bootstrap on at least x86-64 and i386:
../../gcc/ada/ali.adb: In function 'ALI.SCAN_ALI':
../../gcc/ada/ali.adb:2070: error: unrecognizable insn:
(insn:HI 5987 1558 1560 230 ../../gcc/ada/ali.adb:996 (set (plus:SI (reg:SI
2074)
(symbol_ref:SI ("ali__cumulative_restrictions") [flags 0x2]
))
(plus:SI (reg:SI 2074)
(symbol_ref:SI ("ali__cumulative_restrictions") [flags 0x2]
))) -1 (nil)
(nil))
../../gcc/ada/ali.adb: In function 'ALI.SCAN_ALI':
../../gcc/ada/ali.adb:2070: error: unrecognizable insn:
(insn:HI 6040 1461 1463 230 ../../gcc/ada/ali.adb:992 (set (plus:DI (plus:DI
(reg:DI 2096)
(reg/f:DI 726))
(const_int 12 [0xc]))
(plus:DI (reg:DI 2096)
(const:DI (plus:DI (symbol_ref:DI ("ali__cumulative_restrictions")
[flags 0x2] )
(const_int 92 [0x5c]) -1 (nil)
(nil))
Jakub
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20126
[Bug c++/19199] [3.3/3.4/4.0/4.1 Regression] Wrong warning about returning a reference to a temporary
--- Additional Comments From roger at eyesopen dot com 2005-03-09 01:28 --- Subject: Re: [3.3/3.4/4.0/4.1 Regression] Wrong warning about returning a reference to a temporary On 8 Mar 2005, Alexandre Oliva wrote: > > * fold-const.c (non_lvalue): Split tests into... > (maybe_lvalue_p): New function. > (fold_ternary): Use it to avoid turning a COND_EXPR lvalue into > a MIN_EXPR rvalue. This version is Ok for mainline, and currently open release branches. Thanks, Roger -- -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19199
[Bug middle-end/20364] [3.4 Regression] Segfault with -Xpreprocessor argument
--- Additional Comments From wilson at gcc dot gnu dot org 2005-03-09 01:10 --- Fix by the patch I just checked in. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20364
[Bug middle-end/20364] [3.4 Regression] Segfault with -Xpreprocessor argument
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-09 01:01 --- Subject: Bug 20364 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_4-branch Changes by: [EMAIL PROTECTED] 2005-03-09 01:00:56 Modified files: gcc: ChangeLog c-opts.c Log message: Fix for PR middle-end/20364, backported from mainline. Backport from mainline 2004-04-13 James E Wilson <[EMAIL PROTECTED]> PR middle-end/20364 * c-opt.c (c_common_post_options): If this_input_filename is NULL, increment errorcount and return false instead of true. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=2.2326.2.813&r2=2.2326.2.814 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-opts.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.96.4.9&r2=1.96.4.10 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20364
[Bug libgcj/20389] [4.0/4.1 Regression] BufferedInputStream gets ArrayIndexOutOfBoundsExeception
--- Additional Comments From daney at gcc dot gnu dot org 2005-03-09 00:16 --- Patch posted here: http://gcc.gnu.org/ml/java-patches/2005-q1/msg00669.html -- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20389
[Bug driver/13464] -i8 and -r8 not passed correctly to compiler proper. and -d8 does not work
--- Additional Comments From sgk at troutmask dot apl dot washington dot edu 2005-03-08 23:53 --- *** Bug 20390 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||sgk at troutmask dot apl dot ||washington dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13464
[Bug other/20390] Options aren't handled by LANG_HOOKS_HANDLE_OPTIONS
--- Additional Comments From sgk at troutmask dot apl dot washington dot edu 2005-03-08 23:53 --- *** This bug has been marked as a duplicate of 13464 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20390
[Bug driver/13464] -i8 and -r8 not passed correctly to compiler proper. and -d8 does not work
--- Additional Comments From sgk at troutmask dot apl dot washington dot
edu 2005-03-08 23:52 ---
The gfortran frontend defines the two options -i8 and -r8 in gfortran/lang.opt.
gcc/opts.sh appears to process lang.opt without a problem, because the produced
options.h file contains OPT_i8 and OPT_r8. However, neither -i8 nor -r8 is
passed to gfc_handle_option, which is defined to LANG_HOOKS_HANDLE_OPTION
in f95-lang.c.
I have added some debugging printfs to gfc_handle_option
int
gfc_handle_option (size_t scode, const char *arg, int value)
{
int result = 1;
enum opt_code code = (enum opt_code) scode;
printf("code = %d ", code);
if (arg != NULL) printf("arg = %s ", arg);
printf("value = %d\n", value);
The execution of gfortran shows that gfc_handle_option is
never called if -i8 or -r8 is specified.
troutmask:sgk[307] gfc41 -static -o kl -d8 kl.f90
code = 138 value = 1
troutmask:sgk[308] gfc41 -static -o kl -r8 kl.f90
gfc41: unrecognized option '-r8'
troutmask:sgk[309] gfc41 -static -o kl -i8 kl.f90
Note, -d8 is OPT_d8 in options.h and it is passed to gfc_handle_option.
So, it appears that some magic parsing of command line arguments occurs
before gfc_handle_option is called. Is there someway to inhibit this
magic??
BTW, I have a patch that actually makes -d8 work.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13464
[Bug other/20390] Options aren't handled by LANG_HOOKS_HANDLE_OPTIONS
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-08 23:50 --- (In reply to comment #2) > What do you mean by fixed? I mean filed, woops. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20390
[Bug other/20390] Options aren't handled by LANG_HOOKS_HANDLE_OPTIONS
--- Additional Comments From sgk at troutmask dot apl dot washington dot edu 2005-03-08 23:47 --- Subject: Re: Options aren't handled by LANG_HOOKS_HANDLE_OPTIONS On Tue, Mar 08, 2005 at 11:21:52PM -, pinskia at gcc dot gnu dot org wrote: > > --- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-08 > 23:21 --- > This was basically fixed as PR 13464, do you want to close this as a dup and > add your analysis there? > What do you mean by fixed? The -i8 and -r8 options are swallowed before gfc_handle_option is called, and I have a patch that actually fixes -d8. PR 13464 does not show up if one searches bugzilla with "fortran". I'll add what I found. BTW, it I change lang.opt to have -fiate instead of -i8, things works. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20390
[Bug c++/19199] [3.3/3.4/4.0/4.1 Regression] Wrong warning about returning a reference to a temporary
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-03-08
23:23 ---
Subject: Re: [3.3/3.4/4.0/4.1 Regression] Wrong warning about returning a
reference to a temporary
On Mar 7, 2005, Roger Sayle <[EMAIL PROTECTED]> wrote:
> For example, I believe that Alex's proposed solution to PR c++/19199
> isn't an appropriate fix. It's perfectly reasonable for fold to convert
> a C++ COND_EXPR into a MIN_EXPR or MAX_EXPR, as according to the C++
> front-end all three of these tree nodes are valid lvalues. Hence it's
> not this transformation in fold that's in error.
Bugzilla was kept out of the long discussion that ensued, so I'll try
to summarize. The problem is that the conversion is turning a
COND_EXPR such as:
((int)a < (int)b ? a : b)
into
(__typeof(a)) ((int)a Simply disabling the COND_EXPR -> MIN_EXPR/MAX_EXPR transformation is
> also likely to be a serious performance penalty, especially on targets
> that support efficient sequences for "min" and "max".
This was not what I intended to do with my patch, FWIW.
Unfortunately, I goofed in the added call to operand_equal_p, limiting
too much the situations in which the optimization could be applied.
The patch fixes this problem, and updates the patch such that it
applies cleanly again.
As for other languages whose COND_EXPRs can't be lvalues, we can
probably arrange quite easily for them to ensure at least one of their
result operands is not an lvalue, so as to enable the transformation
again.
Comments? Ok to install?
Index: gcc/ChangeLog
from Alexandre Oliva <[EMAIL PROTECTED]>
* fold-const.c (non_lvalue): Split tests into...
(maybe_lvalue_p): New function.
(fold_ternary): Use it to avoid turning a COND_EXPR lvalue into
a MIN_EXPR rvalue.
Index: gcc/fold-const.c
===
RCS file: /cvs/gcc/gcc/gcc/fold-const.c,v
retrieving revision 1.535
diff -u -p -r1.535 fold-const.c
--- gcc/fold-const.c 7 Mar 2005 21:24:21 - 1.535
+++ gcc/fold-const.c 8 Mar 2005 22:07:52 -
@@ -2005,16 +2005,12 @@ fold_convert (tree type, tree arg)
}
}
-/* Return an expr equal to X but certainly not valid as an lvalue. */
+/* Return false if expr can be assumed to not be an lvalue, true
+ otherwise. */
-tree
-non_lvalue (tree x)
+static bool
+maybe_lvalue_p (tree x)
{
- /* While we are in GIMPLE, NON_LVALUE_EXPR doesn't mean anything to
- us. */
- if (in_gimple_form)
-return x;
-
/* We only need to wrap lvalue tree codes. */
switch (TREE_CODE (x))
{
@@ -2054,8 +2050,24 @@ non_lvalue (tree x)
/* Assume the worst for front-end tree codes. */
if ((int)TREE_CODE (x) >= NUM_TREE_CODES)
break;
-return x;
+return false;
}
+
+ return true;
+}
+
+/* Return an expr equal to X but certainly not valid as an lvalue. */
+
+tree
+non_lvalue (tree x)
+{
+ /* While we are in GIMPLE, NON_LVALUE_EXPR doesn't mean anything to
+ us. */
+ if (in_gimple_form)
+return x;
+
+ if (! maybe_lvalue_p (x))
+return x;
return build1 (NON_LVALUE_EXPR, TREE_TYPE (x), x);
}
@@ -9734,10 +9746,16 @@ fold_ternary (tree expr)
of B and C. Signed zeros prevent all of these transformations,
for reasons given above each one.
+We don't want to use operand_equal_for_comparison_p here,
+because it might turn an lvalue COND_EXPR into an rvalue one,
+see PR c++/19199.
+
Also try swapping the arguments and inverting the conditional. */
if (COMPARISON_CLASS_P (arg0)
- && operand_equal_for_comparison_p (TREE_OPERAND (arg0, 0),
-arg1, TREE_OPERAND (arg0, 1))
+ && ((maybe_lvalue_p (op1) && maybe_lvalue_p (op2))
+ ? operand_equal_p (TREE_OPERAND (arg0, 0), op1, 0)
+ : operand_equal_for_comparison_p (TREE_OPERAND (arg0, 0),
+ arg1, TREE_OPERAND (arg0, 1)))
&& !HONOR_SIGNED_ZEROS (TYPE_MODE (TREE_TYPE (arg1
{
tem = fold_cond_expr_with_comparison (type, arg0, op1, op2);
@@ -9746,9 +9764,10 @@ fold_ternary (tree expr)
}
if (COMPARISON_CLASS_P (arg0)
- && operand_equal_for_comparison_p (TREE_OPERAND (arg0, 0),
-op2,
-TREE_OPERAND (arg0, 1))
+ && ((maybe_lvalue_p (op1) && maybe_lvalue_p (op2))
+ ? operand_equal_p (TREE_OPERAND (arg0, 0), op2, 0)
+ : operand_equal_for_comparison_p (TREE_OPERAND (arg0, 0),
+ op2, TREE_OPERAND (arg0, 1)))
&& !HONOR_SIGNED_ZEROS (TYPE_MODE (TREE_TYPE (op2
{
tem = invert_truthvalue (arg0);
Index: gcc/testsuite/ChangeLog
from Alexandre Oliva <[EMAIL PROTECTED]>
PR c++/19199
* g++.dg/expr/lval2.C: New.
Index: gcc/testsuite/g++.dg/expr/
[Bug other/20390] Options aren't handled by LANG_HOOKS_HANDLE_OPTIONS
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-08 23:21 --- This was basically fixed as PR 13464, do you want to close this as a dup and add your analysis there? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20390
[Bug other/20390] New: Options aren't handled by LANG_HOOKS_HANDLE_OPTIONS
The gfortran frontend defines the two options -i8 and -r8 in gfortran/lang.opt.
gcc/opts.sh appears to process lang.opt without a problem, because the produced
options.h file contains OPT_i8 and OPT_r8. However, neither -i8 nor -r8 is
passed to gfc_handle_option, which is defined to LANG_HOOKS_HANDLE_OPTION
in f95-lang.c.
I have added some debugging printfs to gfc_handle_option
int
gfc_handle_option (size_t scode, const char *arg, int value)
{
int result = 1;
enum opt_code code = (enum opt_code) scode;
printf("code = %d ", code);
if (arg != NULL) printf("arg = %s ", arg);
printf("value = %d\n", value);
The execution of gfortran shows that gfc_handle_option is
never called if -i8 or -r8 is specified.
troutmask:sgk[307] gfc41 -static -o kl -d8 kl.f90
code = 138 value = 1
troutmask:sgk[308] gfc41 -static -o kl -r8 kl.f90
gfc41: unrecognized option '-r8'
troutmask:sgk[309] gfc41 -static -o kl -i8 kl.f90
Note, -d8 is OPT_d8 in options.h and it is passed to gfc_handle_option.
So, it appears that some magic parsing of command line arguments occurs
before gfc_handle_option is called. Is there someway to inhibit this
magic??
--
Summary: Options aren't handled by LANG_HOOKS_HANDLE_OPTIONS
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sgk at troutmask dot apl dot washington dot edu
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20390
[Bug target/20331] [3.4/4.0/4.1 Regression] Wrong code generation for the argument of the pure function in PIC
--- Additional Comments From amylaar at gcc dot gnu dot org 2005-03-08 21:58 --- (In reply to comment #1) > I've traced what's going on: > http://gcc.gnu.org/ml/gcc-patches/2005-03/msg00525.html > It includes a patch for comment. > The sh64 port is partcularily exposed in emit_libcall_block because it uses paradoxical subregs to set up the offset part of the PIC address, but I think your patch makes sense. Except that this is only the tip of the iceberg. The problem was introduced in a maga-patch to remove RTX_UNCHANGING_P; there are a number of other places that need to be fixed up similarily. 2004-08-18 Richard Henderson <[EMAIL PROTECTED]> * rtl.h (MEM_READONLY_P): Replace RTX_UNCHANGING_P. * alias.c (true_dependence): Update to match new semantics. (canon_true_dependence, write_dependence_p): Likewise. (anti_dependence, output_dependence): Update write_dependence_p args. (unchanging_anti_dependence): Remove. * calls.c (purge_mem_unchanging_flag): Remove. (fixup_tail_calls): Don't call it. (expand_call): Don't add unchanging memory to function usage. * expr.c (emit_block_move_via_libcall): Likewise. (clear_storage_via_libcall): Don't clobber RTX_UNCHANGING_P mems. (get_subtarget): Don't use RTX_UNCHANGING_P. (expand_assignment, store_constructor, expand_expr_real_1): Likewise. (do_tablejump): Set MEM_READONLY_P, not RTX_UNCHANGING_P. * combine.c (get_last_value_validate): Use MEM_READONLY_P. * cse.c (insert): Don't use RTX_UNCHANGING_P. (cse_insn, canon_hash): Use MEM_READONLY_P. * emit-rtl.c (set_mem_attributes_minus_bitpos): Use MEM_READONLY_P instead of RTX_UNCHANGING_P. * explow.c (maybe_set_unchanging): Remove. * expr.h (maybe_set_unchanging): Remove. * flow.c (insn_dead_p, mark_used_regs): Use anti_dependence. * function.c (assign_stack_temp_for_type): Don't use RTX_UNCHANGING_P. (assign_parm_setup_reg, expand_function_start): Likewise. * integrate.c (copy_rtx_and_substitute): Likewise. * ra-rewrite.c (emit_colors): Likewise. * regmove.c (copy_src_to_dest, regmove_optimize): Likewise. (fixup_match_1): Likewise. * reload1.c (reload, alter_reg): Likewise. * local-alloc.c (validate_equiv_mem): Check MEM_READONLY_P, not RTX_UNCHANGING_P. (equiv_init_varies_p): Likewise. * loop-invariant.c (check_maybe_invariant): Likewise. * resource.c (mark_referenced_resources, mark_set_resources): Likewise. * loop.c (note_addr_stored): Likewise. (prescan_loop): Likewise. Don't check function usage for clobbered unchanging memory. * rtlanal.c (rtx_unstable_p): Check MEM_READONLY_P, not RTX_UNCHANGING_P. (rtx_varies_p, modified_between_p, modified_in_p): Likewise. * varasm.c (force_const_mem): Likewise. * stmt.c (expand_decl): Don't set RTX_UNCHANGING_P. * web.c (entry_register): Likewise. * tree-gimple.h (get_base_address): Move decl ... * tree.h: ... here. * doc/rtl.texi (MEM_READONLY_P): Replace RTX_UNCHANGING_P. * config/alpha/alpha.c (alpha_set_memflags_1): Rewrite to be called via for_each_rtx. Copy MEM_SCALAR_P, MEM_NOTRAP_P too. (alpha_set_memflags): Update to match. * config/darwin.c (machopic_indirect_data_reference): Set MEM_READONLY_P instead of RTX_UNCHANGING_P. (machopic_indirect_call_target): Likewise. (machopic_legitimize_pic_address): Likewise. * config/arm/arm.c (legitimize_pic_address, arm_gen_load_multiple, arm_gen_store_multiple, arm_gen_movmemqi): Likewise. * config/arm/arm.md (load_multiple, store_multiple): Likewise. * config/frv/frv.md (symGOT2reg): Likewise. * config/i386/i386.c (legitimize_pic_address, legitimize_tls_address, ix86_split_to_parts): Likewise. * config/ia64/ia64.c (ia64_expand_tls_address): Likewise. * config/ia64/ia64.md (load_fptr): Likewise. * config/m32r/m32r.c (m32r_legitimize_pic_address): Likewise. * config/m68k/m68k.c (legitimize_pic_address): Likewise. * config/mcore/mcore.c (block_move_sequence): Likewise. * config/mn10300/mn10300.md (symGOT2reg): Likewise. * config/pa/pa.c (legitimize_pic_address): Likewise. * config/rs6000/rs6000.c (rs6000_legitimize_tls_address): Likewise. (rs6000_emit_move): Likewise. * config/s390/s390.c (legitimize_pic_address): Likewise. (legitimize_tls_address): Likewise. * config/s390/s390.md (casesi): Likewise. * config/sh/sh.c (prepare_move_operands, sh_reorg): Likewise. * config/sh/sh.md (symGOT2reg): Likewise. * config/sparc/sparc.c (legitimize_pic_address): Likewise. * config/v850/v850.md (casesi): Likewise. * config/ia64/ia
[Bug c++/20103] [4.0/4.1 regression] ICE in create_tmp_var with C99 style struct initializer
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-03-08
21:55 ---
Subject: Re: [PR c++/20103] failure to gimplify constructors for addressable
types
On Mar 8, 2005, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
> Okie dokie, how about this?
> The change to the gimplify.c is needed to avoid having
> gimple_add_tmp_var twice for the variable, once while expanding the
> declaration/initialization, once while expanding the clean-ups.
> Ok to install? Passed check-g++ (except for the already-broken
> eh/cleanup1.C) on x86_64-linux-gnu; just started bootstrap and full
> reg-testing.
Err... *This* was the one that passed check-g++. The one I posted in
a hurry earlier was very incomplete, and contained fragments of other
patches. Sorry about that.
Index: gcc/ChangeLog
from Alexandre Oliva <[EMAIL PROTECTED]>
PR c++/20103
* gimplify.c (gimplify_decl_expr): Don't add temp variable if it
was already seen in a bind expr.
Index: gcc/gimplify.c
===
RCS file: /cvs/gcc/gcc/gcc/gimplify.c,v
retrieving revision 2.115
diff -u -p -r2.115 gimplify.c
--- gcc/gimplify.c 8 Mar 2005 13:56:57 - 2.115
+++ gcc/gimplify.c 8 Mar 2005 21:48:41 -
@@ -1047,7 +1047,8 @@ gimplify_decl_expr (tree *stmt_p)
/* This decl isn't mentioned in the enclosing block, so add it to the
list of temps. FIXME it seems a bit of a kludge to say that
anonymous artificial vars aren't pushed, but everything else is. */
- if (DECL_ARTIFICIAL (decl) && DECL_NAME (decl) == NULL_TREE)
+ if (DECL_ARTIFICIAL (decl) && DECL_NAME (decl) == NULL_TREE
+ && !DECL_SEEN_IN_BIND_EXPR_P (decl))
gimple_add_tmp_var (decl);
}
Index: gcc/cp/ChangeLog
from Alexandre Oliva <[EMAIL PROTECTED]>
PR c++/20103
* cp-tree.h (build_compound_literal): Declare.
* semantics.c (finish_compound_literal): Move most of the code...
* tree.c (build_compound_literal): ... here. New function.
(lvalue_p_1): Handle COMPOUND_LITERAL_EXPR.
(stabilize_init): Likewise.
* pt.c (tsubst_copy_and_build): Likewise.
* call.c (build_over_call): Likewise.
* class.c (fixed_type_or_null): Likewise.
* cp-gimplify.c (cp_gimplify_init_expr): Likewise.
* cvt.c (force_rvalue, ocp_convert): Likewise.
* typeck.c (build_x_unary_op): Likewise.
(cxx_mark_addressable): Likewise.
(maybe_warn_about_returning_address_of_local): Likewise.
Index: gcc/cp/cp-tree.h
===
RCS file: /cvs/gcc/gcc/gcc/cp/cp-tree.h,v
retrieving revision 1.1107
diff -u -p -r1.1107 cp-tree.h
--- gcc/cp/cp-tree.h 1 Mar 2005 09:57:38 - 1.1107
+++ gcc/cp/cp-tree.h 8 Mar 2005 21:48:50 -
@@ -4218,6 +4218,7 @@ extern tree build_min_nt (enum tree_co
extern tree build_min_non_dep (enum tree_code, tree, ...);
extern tree build_cplus_new(tree, tree);
extern tree get_target_expr(tree);
+extern tree build_compound_literal (tree, tree);
extern tree build_cplus_array_type (tree, tree);
extern tree hash_tree_cons (tree, tree, tree);
extern tree hash_tree_chain(tree, tree);
Index: gcc/cp/semantics.c
===
RCS file: /cvs/gcc/gcc/gcc/cp/semantics.c,v
retrieving revision 1.463
diff -u -p -r1.463 semantics.c
--- gcc/cp/semantics.c 23 Feb 2005 05:30:48 - 1.463
+++ gcc/cp/semantics.c 8 Mar 2005 21:48:52 -
@@ -1980,23 +1980,16 @@ finish_compound_literal (tree type, tree
compound_literal = build_constructor (NULL_TREE, initializer_list);
/* Mark it as a compound-literal. */
TREE_HAS_CONSTRUCTOR (compound_literal) = 1;
+
if (processing_template_decl)
+/* This causes template substitution to run digest_init on the
+ CONSTRUCTOR. */
TREE_TYPE (compound_literal) = type;
else
-{
- /* Check the initialization. */
- compound_literal = digest_init (type, compound_literal, NULL);
- /* If the TYPE was an array type with an unknown bound, then we can
-figure out the dimension now. For example, something like:
-
- `(int []) { 2, 3 }'
-
-implies that the array has two elements. */
- if (TREE_CODE (type) == ARRAY_TYPE && !COMPLETE_TYPE_P (type))
- complete_array_type (type, compound_literal, 1);
-}
+/* Check the initialization. */
+compound_literal = digest_init (type, compound_literal, NULL);
- return compound_literal;
+ return build_compound_literal (type, compound_literal);
}
/* Return the declaration for the function-name variable indicated by
Index: gcc/cp/tree.c
===
RCS file: /cvs/gcc/gcc/gcc/cp/tree.c,v
retrieving revision 1.427
dif
[Bug libgcj/20389] [4.0/4.1 Regression] BufferedInputStream gets ArrayIndexOutOfBoundsExeception
-- What|Removed |Added Status|NEW |ASSIGNED Last reconfirmed|2005-03-08 21:23:11 |2005-03-08 21:32:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20389
[Bug libgcj/20389] [4.0/4.1 Regression] BufferedInputStream gets ArrayIndexOutOfBoundsExeception
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-08 21:23 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Known to work|3.4.3 |3.4.3 3.3.3 Last reconfirmed|-00-00 00:00:00 |2005-03-08 21:23:11 date|| Summary|BufferedInputStream gets|[4.0/4.1 Regression] |ArrayIndexOutOfBoundsExecept|BufferedInputStream gets |ion |ArrayIndexOutOfBoundsExecept ||ion http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20389
[Bug libgcj/20389] BufferedInputStream gets ArrayIndexOutOfBoundsExeception
--- Additional Comments From daney at gcc dot gnu dot org 2005-03-08 21:16 --- Created an attachment (id=8367) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8367&action=view) Testcase As shown in the testcase, a series of marks and reads can cause either ArrayIndexOutOfBoundsException or erroneous EOF. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20389
[Bug libgcj/20389] BufferedInputStream gets ArrayIndexOutOfBoundsExeception
--- Additional Comments From daney at gcc dot gnu dot org 2005-03-08 21:13 --- I will attach a testcase. I also have a tentative patch and Mauve test that I will submit shortly. -- What|Removed |Added GCC build triplet||i686-pc-linux GCC host triplet||i686-pc-linux GCC target triplet||i686-pc-linux Known to fail||4.0.0 4.1.0 Known to work||3.4.3 Summary|Buffere |BufferedInputStream gets ||ArrayIndexOutOfBoundsExecept ||ion http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20389
[Bug libgcj/20389] Buffere
-- What|Removed |Added Summary|Buff|Buffere http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20389
[Bug libgcj/20389] New: Buff
-- Summary: Buff Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libgcj AssignedTo: daney at gcc dot gnu dot org ReportedBy: daney at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20389
[Bug middle-end/20364] [3.4 Regression] Segfault with -Xpreprocessor argument
--- Additional Comments From wilson at gcc dot gnu dot org 2005-03-08 20:53 --- Hint taken. I'm testing the patch with gcc-3.4, and then will check it in if there are no problems. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |wilson at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-03-07 18:58:59 |2005-03-08 20:53:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20364
[Bug rtl-optimization/20367] alias analysis doesn't take into account that variables that haven't their address taken can't alias arbitrary MEMs
--- Additional Comments From amylaar at gcc dot gnu dot org 2005-03-08 20:51 --- (In reply to comment #16) > And that should be fixed via the structure aliasing improvements that Daniel is working on. Will this also work when a[0] .. a[2] are replaced with a0 .. a2 ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20367
[Bug c++/20103] [4.0/4.1 regression] ICE in create_tmp_var with C99 style struct initializer
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-03-08
20:44 ---
Subject: Re: [PR c++/20103] failure to gimplify constructors for addressable
types
On Mar 8, 2005, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> No, because there would be no TARGET_EXPR. In a template, you would
> just have a COMPOUND_LITERAL_EXPR, with no TARGET_EXPR, because we
> want a syntactic representation of the input program.
> Yes, and introducing TARGET_EXPRs into templates *is a bug* because in
> templates we want a syntactic representation. The closest thing we
> have to a syntactic representation of a compound literal is a
> CONSTRUCTOR; it's certainly not a TARGET_EXPR wrapped around a
> CONSTRUCTOR. It may be just fine to use CONSTRUCTOR, instead of
> introducing COMPOUND_LITERAL_EXPR, but TARGET_EXPRs should not be
> appearing here at all.
> Unfortunately, you've also caused me to think about this long enough
> to realize that having the TARGET_EXPR here is wrong in the first
> place, as per above.
Okie dokie, how about this?
The change to the gimplify.c is needed to avoid having
gimple_add_tmp_var twice for the variable, once while expanding the
declaration/initialization, once while expanding the clean-ups.
Ok to install? Passed check-g++ (except for the already-broken
eh/cleanup1.C) on x86_64-linux-gnu; just started bootstrap and full
reg-testing.
Index: gcc/ChangeLog
from Alexandre Oliva <[EMAIL PROTECTED]>
PR c++/20103
* gimplify.c (gimplify_decl_expr): Don't add temp variable if it
was already seen in a bind expr.
Index: gcc/gimplify.c
===
RCS file: /cvs/gcc/gcc/gcc/gimplify.c,v
retrieving revision 2.115
diff -u -p -r2.115 gimplify.c
--- gcc/gimplify.c 8 Mar 2005 13:56:57 - 2.115
+++ gcc/gimplify.c 8 Mar 2005 20:33:03 -
@@ -1047,7 +1047,8 @@ gimplify_decl_expr (tree *stmt_p)
/* This decl isn't mentioned in the enclosing block, so add it to the
list of temps. FIXME it seems a bit of a kludge to say that
anonymous artificial vars aren't pushed, but everything else is. */
- if (DECL_ARTIFICIAL (decl) && DECL_NAME (decl) == NULL_TREE)
+ if (DECL_ARTIFICIAL (decl) && DECL_NAME (decl) == NULL_TREE
+ && !DECL_SEEN_IN_BIND_EXPR_P (decl))
gimple_add_tmp_var (decl);
}
@@ -2123,7 +2124,8 @@ gimple_boolify (tree expr)
*EXPR_P should be stored. */
static enum gimplify_status
-gimplify_cond_expr (tree *expr_p, tree *pre_p, tree *post_p, tree target)
+gimplify_cond_expr (tree *expr_p, tree *pre_p, tree *post_p, tree target,
+ fallback_t fallback)
{
tree expr = *expr_p;
tree tmp, tmp2, type;
@@ -2137,18 +2139,40 @@ gimplify_cond_expr (tree *expr_p, tree *
the arms. */
else if (! VOID_TYPE_P (type))
{
+ tree result;
+
if (target)
{
ret = gimplify_expr (&target, pre_p, post_p,
is_gimple_min_lval, fb_lvalue);
if (ret != GS_ERROR)
ret = GS_OK;
- tmp = target;
+ result = tmp = target;
tmp2 = unshare_expr (target);
}
+ else if ((fallback & fb_lvalue) == 0)
+ {
+ result = tmp2 = tmp = create_tmp_var (TREE_TYPE (expr), "iftmp");
+ ret = GS_ALL_DONE;
+ }
else
{
- tmp2 = tmp = create_tmp_var (TREE_TYPE (expr), "iftmp");
+ tree type = build_pointer_type (TREE_TYPE (expr));
+
+ if (TREE_TYPE (TREE_OPERAND (expr, 1)) != void_type_node)
+ TREE_OPERAND (expr, 1) =
+ build_fold_addr_expr (TREE_OPERAND (expr, 1));
+
+ if (TREE_TYPE (TREE_OPERAND (expr, 2)) != void_type_node)
+ TREE_OPERAND (expr, 2) =
+ build_fold_addr_expr (TREE_OPERAND (expr, 2));
+
+ tmp2 = tmp = create_tmp_var (type, "iftmp");
+
+ expr = build (COND_EXPR, void_type_node, TREE_OPERAND (expr, 0),
+ TREE_OPERAND (expr, 1), TREE_OPERAND (expr, 2));
+
+ result = build_fold_indirect_ref (tmp);
ret = GS_ALL_DONE;
}
@@ -2169,7 +2193,7 @@ gimplify_cond_expr (tree *expr_p, tree *
/* Move the COND_EXPR to the prequeue. */
gimplify_and_add (expr, pre_p);
- *expr_p = tmp;
+ *expr_p = result;
return ret;
}
@@ -2907,7 +2931,8 @@ gimplify_modify_expr_rhs (tree *expr_p,
if (!is_gimple_reg_type (TREE_TYPE (*from_p)))
{
*expr_p = *from_p;
- return gimplify_cond_expr (expr_p, pre_p, post_p, *to_p);
+ return gimplify_cond_expr (expr_p, pre_p, post_p, *to_p,
+ fb_rvalue);
}
else
ret = GS_UNHANDLED;
@@ -3721,7 +3746,8 @@ gimplify_expr (tree *expr_p, tree *pre_p
break;
case COND_EXPR:
- ret = gimplify_cond_expr (expr_p, pre_p, post_p, NULL_TREE);
+ ret = gimplify
[Bug fortran/15080] Forall bounds not calculated correctly (forall_3.f90)
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-08 20:30 --- On i686-pc-linux-gnu, forall_5.f90 does the following: $ gfortran forall_5.f90 $ ./a.out Fortran runtime error: Attempt to allocate a negative amount of memory. $ gfortran -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.0/configure --prefix=/home/ig25 --enable-languages=c,f95 Thread model: posix gcc version 4.0.0 20050306 (prerelease) Did I mention I don't like memory corruption? Thomas -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15080
[Bug fortran/20387] ICE in gfc_conv_array_initializer
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-08 20:11 --- Looks like we don't handle EXPR_ARRAY in gfc_conv_array_initializer, if we have 100 or less we get EXPR_CONSTANT. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20387
[Bug java/20388] gcj should have a -print-libgcj-jar-file-name option
-- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-03-08 19:49:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20388
[Bug fortran/20387] ICE in gfc_conv_array_initializer
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-08 19:49 --- Confirmed, reduced testcase which shows where the problem is (one less initializer and it will work): module bug04 integer, dimension(101), parameter, private :: a = (/ & 2,3,5,7, 11, 13, 17, 19, 23, 29, & 31, 37, 41, 43, 47, 53, 59, 61, 67, 71, & 73, 79, 83, 89, 97, 101, 103, 107, 109, 113, & 127, 131, 137, 139, 149, 151, 157, 163, 167, 173, & 179, 181, 191, 193, 197, 199, 211, 223, 227, 229, & 233, 239, 241, 251, 257, 263, 269, 271, 277, 281, & 283, 293, 307, 311, 313, 317, 331, 337, 347, 349, & 353, 359, 367, 373, 379, 383, 389, 397, 401, 409, & 419, 421, 431, 433, 439, 443, 449, 457, 461, 463, & 467, 479, 487, 491, 499, 503, 509, 521, 523, 541, & 547 /) integer, dimension(101), public :: b=(/ a /) contains end module bug04 -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2005-03-08 19:49:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20387
[Bug java/20388] gcj should have a -print-libgcj-jar-file-name option
-- What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20388
[Bug java/20388] New: gcj should have a -print-libgcj-jar-file-name option
To locate gcj's version-specific jni.h header, we use: gcj -print-file-name=include/jni.h We should have a similar way to print the libgcj.jar file name. This would be useful for packagers. -- Summary: gcj should have a -print-libgcj-jar-file-name option Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fitzsim at redhat dot com CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20388
[Bug fortran/20387] New: ICE in gfc_conv_array_initializer
>From http://www.cs.kuleuven.ac.be/~bartv/downloads/bug04.f95: $ gfortran bug04.f90 bug04.f90:0: internal compiler error: in gfc_conv_array_initializer, at fortran/trans-array.c:2936 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. $ gfortran -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.0/configure --prefix=/home/ig25 --enable-languages=c,f95 Thread model: posix gcc version 4.0.0 20050306 (prerelease) $ cat bug04.f90 module bug04 integer, dimension(300), parameter, private :: primes_1_to_300 = (/ & 2,3,5,7, 11, 13, 17, 19, 23, 29, & 31, 37, 41, 43, 47, 53, 59, 61, 67, 71, & 73, 79, 83, 89, 97, 101, 103, 107, 109, 113, & 127, 131, 137, 139, 149, 151, 157, 163, 167, 173, & 179, 181, 191, 193, 197, 199, 211, 223, 227, 229, & 233, 239, 241, 251, 257, 263, 269, 271, 277, 281, & 283, 293, 307, 311, 313, 317, 331, 337, 347, 349, & 353, 359, 367, 373, 379, 383, 389, 397, 401, 409, & 419, 421, 431, 433, 439, 443, 449, 457, 461, 463, & 467, 479, 487, 491, 499, 503, 509, 521, 523, 541, & 547, 557, 563, 569, 571, 577, 587, 593, 599, 601, & 607, 613, 617, 619, 631, 641, 643, 647, 653, 659, & 661, 673, 677, 683, 691, 701, 709, 719, 727, 733, & 739, 743, 751, 757, 761, 769, 773, 787, 797, 809, & 811, 821, 823, 827, 829, 839, 853, 857, 859, 863, & 877, 881, 883, 887, 907, 911, 919, 929, 937, 941, & 947, 953, 967, 971, 977, 983, 991, 997, 1009, 1013, & 1019, 1021, 1031, 1033, 1039, 1049, 1051, 1061, 1063, 1069, & 1087, 1091, 1093, 1097, 1103, 1109, 1117, 1123, 1129, 1151, & 1153, 1163, 1171, 1181, 1187, 1193, 1201, 1213, 1217, 1223, & 1229, 1231, 1237, 1249, 1259, 1277, 1279, 1283, 1289, 1291, & 1297, 1301, 1303, 1307, 1319, 1321, 1327, 1361, 1367, 1373, & 1381, 1399, 1409, 1423, 1427, 1429, 1433, 1439, 1447, 1451, & 1453, 1459, 1471, 1481, 1483, 1487, 1489, 1493, 1499, 1511, & 1523, 1531, 1543, 1549, 1553, 1559, 1567, 1571, 1579, 1583, & 1597, 1601, 1607, 1609, 1613, 1619, 1621, 1627, 1637, 1657, & 1663, 1667, 1669, 1693, 1697, 1699, 1709, 1721, 1723, 1733, & 1741, 1747, 1753, 1759, 1777, 1783, 1787, 1789, 1801, 1811, & 1823, 1831, 1847, 1861, 1867, 1871, 1873, 1877, 1879, 1889, & 1901, 1907, 1913, 1931, 1933, 1949, 1951, 1973, 1979, 1987 /) integer, dimension(300), parameter, private :: primes_301_to_600 = (/ & 1993, 1997, 1999, 2003, 2011, 2017, 2027, 2029, 2039, 2053, & 2063, 2069, 2081, 2083, 2087, 2089, 2099, 2111, 2113, 2129, & 2131, 2137, 2141, 2143, 2153, 2161, 2179, 2203, 2207, 2213, & 2221, 2237, 2239, 2243, 2251, 2267, 2269, 2273, 2281, 2287, & 2293, 2297, 2309, 2311, 2333, 2339, 2341, 2347, 2351, 2357, & 2371, 2377, 2381, 2383, 2389, 2393, 2399, 2411, 2417, 2423, & 2437, 2441, 2447, 2459, 2467, 2473, 2477, 2503, 2521, 2531, & 2539, 2543, 2549, 2551, 2557, 2579, 2591, 2593, 2609, 2617, & 2621, 2633, 2647, 2657, 2659, 2663, 2671, 2677, 2683, 2687, & 2689, 2693, 2699, 2707, 2711, 2713, 2719, 2729, 2731, 2741, & 2749, 2753, 2767, 2777, 2789, 2791, 2797, 2801, 2803, 2819, & 2833, 2837, 2843, 2851, 2857, 2861, 2879, 2887, 2897, 2903, & 2909, 2917, 2927, 2939, 2953, 2957, 2963, 2969, 2971, 2999, & 3001, 3011, 3019, 3023, 3037, 3041, 3049, 3061, 3067, 3079, & 3083, 3089, 3109, 3119, 3121, 3137, 3163, 3167, 3169, 3181, & 3187, 3191, 3203, 3209, 3217, 3221, 3229, 3251, 3253, 3257, & 3259, 3271, 3299, 3301, 3307, 3313, 3319, 3323, 3329, 3331, & 3343, 3347, 3359, 3361, 3371, 3373, 3389, 3391, 3407, 3413, & 3433, 3449, 3457, 3461, 3463, 3467, 3469, 3491, 3499, 3511, & 3517, 3527, 3529, 3533, 3539, 3541, 3547, 3557, 3559, 3571, & 3581, 3583, 3593, 3607, 3613, 3617, 3623, 3631, 3637, 3643, & 3659, 3671, 3673, 3677, 3691, 3697, 3701, 3709, 3719, 3727, & 3733, 3739, 3761, 3767, 3769, 3779, 3793, 3797, 3803, 3821, & 3823, 3833, 3847, 3851, 3853, 3863, 3877, 3881, 3889, 3907, & 3911, 3917, 3919, 3923, 3929, 3931, 3943, 3947, 3967, 3989, & 4001, 4003, 4007, 4013, 4019, 4021, 4027, 4049, 4051, 4057, & 4073, 4079, 4091, 4093, 4099, 4111, 4127, 4129, 4133, 4139, & 4153, 4157, 4159, 4177, 4201, 4211, 4217, 4219, 4229, 4231, & 4241, 4243, 4253, 4259, 4261, 4271, 4273, 4283, 4289, 4297, & 4327, 4337, 4339, 4349, 4357, 4363, 4373, 4391, 4397, 4409 /) integer, dimension(300), parameter, private :: primes_601_to_900 = (/ & 4421, 4423, 4441, 4447, 4451, 4457, 4463, 4481, 4483, 4493, & 4507, 4513, 4517, 4519, 4523, 4547, 4549, 4561, 4567, 4583, & 4591, 4597, 4603, 4621, 4637, 4639, 4643, 4649, 4651, 4657, & 4663,
[Bug other/17652] [meta-bug] GCC 4.1 pending patches
-- Bug 17652 depends on bug 14411, which changed state. Bug 14411 Summary: Request for setjmp/longjmp attributes http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14411 What|Old Value |New Value Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17652
[Bug c/14411] Request for setjmp/longjmp attributes
--- Additional Comments From avn at any dot ru 2005-03-08 19:02 --- Actually, it is fixed. The other two patches that I pinged are not related to this PR. -- What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14411
[Bug c/20385] Lame error message for undefined type
--- Additional Comments From joseph at codesourcery dot com 2005-03-08
18:59 ---
Subject: Re: New: Lame error message for undefined type
On Tue, 8 Mar 2005, falk at debian dot org wrote:
> % cat test.c
> unknowntype f() { return 0; }
>
> % gcc -c test.c
> test.c:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'f'
>
> Firstly, since this is a frequent mistake, we should really be able to produce
> "unknowntype used like a type", as other compilers do.
>
> Secondly, IMHO this kind of "expected ..." error message is *never* a good
> idea. I cannot recall a single instance where it was actually helpful to me,
> and very often, as in this case, it is extremely confusing, and I would be
> better off with plain "syntax error before f" as it used to be in the old
> parser. Even though my knowledge of C parsing is probably slightly above
> average, I have not the slightest idea why the parser expects '=', ',', ';',
> 'asm' or '__attribute__' here, and what I can derive from that about the
> mistake I made. But maybe that's just me.
Functions can be defined without declaration specifiers in C90. GNU C
also allows (but pedwarns for) definitions (at file scope) of objects with
no declaration specifiers (for example, "*foo;" meaning "int *foo;"). So
"unknowntype" has been parsed as the name being declared at this point.
So it must either be a function definition of a function called
"unknowntype" (which it isn't as the declaration isn't a function one) or
a data declaration, and the tokens listed are those which would follow
"unknowntype" in a data declaration (for example, "unknowntype = 1; f()
...").
It would be possible to have special-case detection for where empty
declaration specifiers are followed by a declarator consisting only of an
identifier, unparenthesised, and in the case of a parse error act like
that identifier was a type and look for a new declarator. This would
cover "unknowntype foo;" and "unknowntype *foo;". You can't detect
undeclared types in full generality; for example,
unknowntype (foo)() { return 0; }
is syntactically valid C90 which should be diagnosed, as it is at present,
as declaring a function "unknowntype" returning a function and so breaking
a constraint, rather than the compiler second-guessing that "unknowntype"
is a type and "(foo)" is the parenthesised function name.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20385
[Bug c/20385] Lame error message for undefined type
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-08 18:33 --- The `new' C++ parser gives the best error message: t.c:1: error: 'unknowntype' does not name a type -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-03-08 18:33:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20385
[Bug tree-optimization/20386] New: Missing computed goto to normal goto optimization
We miss a computed goto to non computed got if there is code between the
assignment and the goto:
void g();
int f(int i)
{
void *a;
if (i) a = &&l1;
else a = &&l2;
g();
goto *a;
l1:
return 1;
l2:
return 2;
}
I saw this while debugging PR13024.java and why if I tried compiling it with
javac it passed.
That function should be equivalent to the following:
void g();
int f(int i)
{
void *a;
g();
if (i) a = &&l1;
else a = &&l2;
goto *a;
l1:
return 1;
l2:
return 2;
}
where we check i is not revalant here.
--
Summary: Missing computed goto to normal goto optimization
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20386
[Bug c/20385] New: Lame error message for undefined type
% cat test.c
unknowntype f() { return 0; }
% gcc -c test.c
test.c:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'f'
Firstly, since this is a frequent mistake, we should really be able to produce
"unknowntype used like a type", as other compilers do.
Secondly, IMHO this kind of "expected ..." error message is *never* a good
idea. I cannot recall a single instance where it was actually helpful to me,
and very often, as in this case, it is extremely confusing, and I would be
better off with plain "syntax error before f" as it used to be in the old
parser. Even though my knowledge of C parsing is probably slightly above
average, I have not the slightest idea why the parser expects '=', ',', ';',
'asm' or '__attribute__' here, and what I can derive from that about the
mistake I made. But maybe that's just me.
--
Summary: Lame error message for undefined type
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: falk at debian dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20385
[Bug rtl-optimization/20367] alias analysis doesn't take into account that variables that haven't their address taken can't alias arbitrary MEMs
--- Additional Comments From giovannibajo at libero dot it 2005-03-08 18:18 --- (In reply to comment #10) > >So, to recap: testcase in comment #5 should not be optimized (at least, > >it is > >not related to this bug). > Actually, it is related inasmuch as it demonstrates a pitfall you have > to avoid Right. We then should prepare a testcase from this code that scans the ivopts dump to check that the IV is not strength reduced or something like that. > It still makes sense to also handle this at the rtl level, so that the > scheduler knows that > the MEMs don't alias. Unless you propose to convert sched1 and sched2 to do > machine-independent scheduling on trees ;-) To tell you the truth, I would like the expanders to somehow preserve tree aliasing information while creating RTL. But this is gonna be post 4.1 anyway since nobody is working on it, so yes, you are right, for now we want to handle this at RTL level too. Can you show us the SH code generated by mainline for the testcase in comment #2? Or otherwise provide another testcase where the scheduling conflict is visible? -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-03-08 18:18:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20367
[Bug bootstrap/13993] [3.4 Regression] Relative path as srcdir causes problem
--- Additional Comments From drow at gcc dot gnu dot org 2005-03-08 17:31 --- Fixed on 3.4 and 4.0 branches. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13993
[Bug rtl-optimization/13024] [3.4 regression] gcj can't build current rhug
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-08 17:31 --- Hmm, this fails on the mainline again: PR13024.java: In class 'PR13024':^MPR13024.java: In method 'PR13024.isZipOrJarArchive(java.io.File)': ^MPR13024.java:0: error: dominator of 3 should be 2, not 0^M PR13024.java:0: internal compiler error: in verify_dominators, at dominance.c:854^M Please submit a full bug report,^Mwith preprocessed source if appropriate.^M See http://gcc.gnu.org/bugs.html> for instructions.^M I think this was caused by Jeff's patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13024
[Bug java/20384] Can't compile oracle test jdbc app with oracle jdbc14.jar shared lib version
--- Additional Comments From delarosa at ilstechnology dot com 2005-03-08 16:49 --- Thanks, --main fixed it. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20384
Re: Rq4Clarification: std::uncaught_exception
Attila Feher F (JO/LMF) wrote: Hi, I have been reading http://gcc.gnu.org/bugs.html, but I cannot figure out if the bug I have found in the way std::uncaught_exception works is a gcc or a libstdc++ bug. Since the faulty behavior is the same with MinGW and Linux native gcc, I guess it is a language/compiler issue. (The bug is that std::uncaught_exception returns false in a corner case, when the standard asks for true return. I think it is probably the least important issue, but I still would like to get it registered somewhere.) Please let me know where should I report this bug! You might find this bug report helpful: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10606 Martin
[Bug java/20384] Can't compile oracle test jdbc app with oracle jdbc14.jar shared lib version
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-08 16:40 --- -main=jdbcTester You want --main= jdbcTester -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20384
[Bug java/20384] New: Can't compile oracle test jdbc app with oracle jdbc14.jar shared lib version
gcj -O2 -shared -fjni -findirect-dispatch ojdbc14.jar -o ojdbc14.so gcj -o oracletest -O2 --classpath=/home/acuser/gcj/DB/ojdbc14.jar jdbcTester.java -main=jdbcTester /home/acuser/gcj/DB/ojdbc14.so -L /usr/local/lib -lgcj jc1: error: invalid option ΓÇÿain=jdbcTesterΓÇÖ make: *** [oracletest] Error 1 -- Summary: Can't compile oracle test jdbc app with oracle jdbc14.jar shared lib version Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: delarosa at ilstechnology dot com CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20384
[Bug fortran/15080] Forall bounds not calculated correctly (forall_3.f90)
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-08 15:35 --- Here's a somewhat reduced testcase that fails for me on ia64-unknown-linux-gnu: $ cat forall_5.f90 program evil_forall implicit none type t logical valid integer :: s integer, dimension(:), pointer :: p end type type (t), dimension (2) :: v integer i allocate (v(1)%p(2)) allocate (v(2)%p(2)) v(:)%valid = (/.true., .true./) v(:)%s = (/1, 2/) v(1)%p(:) = (/9, 10/) v(2)%p(:) = (/11, 12/) forall (i=1:2,v(i)%valid) v(i)%p(1:v(i)%s) = v(3-i)%p(1:v(i)%s) end forall if (any(v(1)%p(:) .ne. (/11, 10/))) call abort end program Still gives me 335 lines of *.t02.original - not easy to debug... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15080
[Bug c++/20383] [3.3/3.4 Regression] #line directive breaks try-catch statement
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-08 15:21 --- Fixed by the merge of the tree-ssa : Search converges between 2004-05-11-trunk (#454) and 2004-05-14-trunk (#455). Broke: : Search converges between 2002-01-13-trunk (#54) and 2002-01-20-trunk (#55). -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||rejects-valid Known to fail||3.4.3 3.0.4 3.3.3 Known to work||2.95.3 4.0.0 Last reconfirmed|-00-00 00:00:00 |2005-03-08 15:21:31 date|| Summary|#line directive breaks try- |[3.3/3.4 Regression] #line |catch statement |directive breaks try-catch ||statement Target Milestone|--- |3.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20383
[Bug c++/20383] New: #line directive breaks try-catch statement
The following legal input produces the error message:
"`...' handler must be the last handler for its try block".
int main () {
try {}
#line 1 "xxx"
catch (int) {}
}
--
Summary: #line directive breaks try-catch statement
Product: gcc
Version: 3.3.4
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: heinlein at informatik dot uni-ulm dot de
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20383
[Bug other/17652] [meta-bug] GCC 4.1 pending patches
-- Bug 17652 depends on bug 20367, which changed state. Bug 20367 Summary: alias analysis doesn't take into account that variables that haven't their address taken can't alias arbitrary MEMs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20367 What|Old Value |New Value Status|RESOLVED|UNCONFIRMED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17652
[Bug rtl-optimization/20367] alias analysis doesn't take into account that variables that haven't their address taken can't alias arbitrary MEMs
--- Additional Comments From amylaar at gcc dot gnu dot org 2005-03-08 15:10 --- You have not addressed the scheduling issues. -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20367
[Bug c/18978] [3.4 Regression] Segfault after a warning about 'struct sigaction'
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-03-08 14:58 --- *** Bug 20379 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||wei dot feng at sybase dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18978
[Bug c/20379] Segfault after struct declared inside parameter list
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-03-08 14:58 --- ... to mark as duplicate of PR 18978. *** This bug has been marked as a duplicate of 18978 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20379
[Bug c/20379] Segfault after struct declared inside parameter list
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-03-08 14:57 --- Reopen ... -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20379
[Bug middle-end/19985] executables created with -fprofile-arcs -ftest-coverage segfault in gcov_exit ()
-- What|Removed |Added Severity|critical|normal Keywords|wrong-code | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19985
[Bug c/20379] Segfault after struct declared inside parameter list
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-08 14:49 --- Lets close this as fixed then. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |3.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20379
[Bug other/17652] [meta-bug] GCC 4.1 pending patches
-- Bug 17652 depends on bug 14411, which changed state. Bug 14411 Summary: Request for setjmp/longjmp attributes http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14411 What|Old Value |New Value Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17652
[Bug other/17652] [meta-bug] GCC 4.1 pending patches
-- Bug 17652 depends on bug 14411, which changed state. Bug 14411 Summary: Request for setjmp/longjmp attributes http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14411 What|Old Value |New Value Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17652
[Bug c/14411] Request for setjmp/longjmp attributes
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-08 14:38 --- Actually I take that back, it is only 1 out of 3 which was applied. -- What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14411
[Bug c/14411] Request for setjmp/longjmp attributes
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-08 14:36 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14411
[Bug libstdc++/20352] FAIL: 26_numerics/complex/pow.cc execution test
--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca 2005-03-08 14:35 --- Subject: Re: FAIL: 26_numerics/complex/pow.cc execution test > Digging more (in C99 and Posix), it seems that pow(x,y) always behaves the > same > for x == +0 and x == -0: this would imply that probably it's safe to have in > the generic code something like the attached (vs mainline, very same change > also for 4.0 and 3.4). And should also improve the QoI of complex::pow(0, 0), > aligning it to the real case, as per F.9.4.4 > > Can you test it on the targets you have access to? This fixes the fail on hppa1.1-hp-hpux10.20. Also tested with no regressions on hppa2.0w-hp-hpux11.11 (4.1.0), hppa64-hp-hpux11.11 (4.1.0) and hppa-unknown-linux-gnu (4.0.0). Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20352
[Bug target/20375] [4.0/4.1 Regression] C++ ICE in assign_parm_find_entry_rtl
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |nathan at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-03-08 14:29:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20375
[Bug ada/20035] failed run-time assertion : Tasking not implemented on this configuration on sparc-linux
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-08 14:29 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20035
[Bug inline-asm/20382] internal compiler error with bogus asm output constraint
--- Additional Comments From falk at debian dot org 2005-03-08 14:25
---
Confirmed. This is triggered by a bogus argument for an output constraint.
Not a regression.
void f() {
__asm__ ("" : "=r" ("r5"), "+r" ("r5"));
}
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|middle-end |inline-asm
Ever Confirmed||1
GCC build triplet|3.3.1-macraigor1|
GCC host triplet|3.4.0 |
GCC target triplet|3.3.1 |
Keywords||ice-on-invalid-code
Known to fail||2.95.4 3.2.3 3.3.5 3.4.3
||4.1.0
Summary|internal compiler error in |internal compiler error with
|emit_move_insn, at |bogus asm output constraint
|expr.c:2809 |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20382
[Bug rtl-optimization/20367] alias analysis doesn't take into account that variables that haven't their address taken can't alias arbitrary MEMs
--- Additional Comments From joern dot rennecke at st dot com 2005-03-08 14:21 --- Subject: Re: alias analysis doesn't take into account that variables that haven't their address taken can't alias arbitrary MEMs giovannibajo at libero dot it wrote: >--- Additional Comments From giovannibajo at libero dot it 2005-03-08 >12:30 --- >So, to recap: testcase in comment #5 should not be optimized (at least, it is >not related to this bug). > Actually, it is related inasmuch as it demonstrates a pitfall you have to avoid. > Testcase in comment #2 is already optimized correctly >in the tree-profiling-branch, which is due to be merged for 4.1. > >If so, we can suspend this bug until the branch is merged. The proposed patch >cannot be merged to release branches because this is not a regression, AFAICT. > >I also guess that on the mainline we want to fix this at the tree level. > It still makes sense to also handle this at the rtl level, so that the scheduler knows that the MEMs don't alias. Unless you propose to convert sched1 and sched2 to do machine-independent scheduling on trees ;-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20367
[Bug c++/20381] [4.0/4.1 Regression] ICE in build_ptrmemfunc, at cp/typeck.c:5702
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-08 14:12 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||ice-on-valid-code Known to fail||4.0.0 4.1.0 Known to work||3.4.0 Last reconfirmed|-00-00 00:00:00 |2005-03-08 14:12:44 date|| Summary|ICE in build_ptrmemfunc, at |[4.0/4.1 Regression] ICE in |cp/typeck.c:5702|build_ptrmemfunc, at ||cp/typeck.c:5702 Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20381
[Bug middle-end/20382] internal compiler error in emit_move_insn, at expr.c:2809
-- What|Removed |Added Component|c |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20382
[Bug other/17652] [meta-bug] GCC 4.1 pending patches
-- Bug 17652 depends on bug 20367, which changed state. Bug 20367 Summary: alias analysis doesn't take into account that variables that haven't their address taken can't alias arbitrary MEMs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20367 What|Old Value |New Value Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17652
[Bug rtl-optimization/20367] alias analysis doesn't take into account that variables that haven't their address taken can't alias arbitrary MEMs
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-08 14:07 --- (In reply to comment #8) > So, to recap: testcase in comment #5 should not be optimized (at least, it is > not related to this bug). Testcase in comment #2 is already optimized > correctly > in the tree-profiling-branch, which is due to be merged for 4.1. Nope the testcase in comment #2 is already optimizated on the mainline (and in 4.0.0) so this could be closed as fixed. Now the one in Comment #5 is a dup of bug 19905 so this could be closed as fixed for 4.0.0 and not worried about. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20367
[Bug rtl-optimization/20359] [3.3/3.4 regression] Incorrect code with global register variables
--- Additional Comments From jakub at gcc dot gnu dot org 2005-03-08 14:01
---
Seems to be the combiner, that combines:
(insn 8 22 10 0 (set (reg/v:DI 42 r13 [ r ])
(symbol_ref:DI ("g") [flags 0x3] )) 84
{*movdi_1_rex64_nointerunit} (nil)
(nil))
(insn 10 8 12 0 (set (reg:DI 59 [ r ])
(reg/v:DI 42 r13 [ r ])) 84 {*movdi_1_rex64_nointerunit} (insn_list 8
(nil))
(expr_list:REG_DEAD (reg/v:DI 42 r13 [ r ])
(nil)))
into:
(insn 10 8 12 0 (set (reg:DI 59 [ r ])
(symbol_ref:DI ("g") [flags 0x3] )) 84
{*movdi_1_rex64_nointerunit} (nil)
(nil))
without taking into account that there is a hard reg assignment.
This means it is not certain that the problem is not present in 4.0/4.1 as well,
just that combiner is not presented the same *.life RTLs and therefore makes
different decisions.
In 4.0, *.life looks like:
(insn 8 6 9 0 (set (reg/v:DI 42 r13 [ r ])
(symbol_ref:DI ("g") [flags 0x3] )) 81
{*movdi_1_rex64} (nil)
(expr_list:REG_UNUSED (reg/v:DI 42 r13 [ r ])
(nil)))
(insn 9 8 10 0 (set (reg/f:DI 59)
(symbol_ref:DI ("g") [flags 0x3] )) 81
{*movdi_1_rex64} (nil)
(nil))
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20359
[Bug c/14411] Request for setjmp/longjmp attributes
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-08 13:19 --- Subject: Bug 14411 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-03-08 13:19:41 Modified files: gcc: ChangeLog c-common.c calls.c tree.h gcc/doc: extend.texi Added files: gcc/testsuite/gcc.dg: attr-returns_twice-1.c Log message: PR c/14411 * calls.c (flags_from_decl_or_type): Handle eturns_twice' attribute. * c-common.c (handle_returns_twice): New function. (c_common_attribute_table): Declare eturns_twice' attribute. * doc/extend.texi: Document eturns_twice' attribute. * tree.h (DECL_IS_RETURNS_TWICE): New macro. (struct tree_decl): Add returns_twice_flag. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.7728&r2=2.7729 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-common.c.diff?cvsroot=gcc&r1=1.606&r2=1.607 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/calls.c.diff?cvsroot=gcc&r1=1.380&r2=1.381 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree.h.diff?cvsroot=gcc&r1=1.698&r2=1.699 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/doc/extend.texi.diff?cvsroot=gcc&r1=1.242&r2=1.243 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/attr-returns_twice-1.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14411
[Bug c/20382] internal compiler error in emit_move_insn, at expr.c:2809
--- Additional Comments From sailors3 at comcast dot net 2005-03-08 13:14 --- Created an attachment (id=8361) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8361&action=view) command line that triggered bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20382
[Bug c/20382] internal compiler error in emit_move_insn, at expr.c:2809
--- Additional Comments From sailors3 at comcast dot net 2005-03-08 13:13 --- Created an attachment (id=8360) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8360&action=view) preprocessed input file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20382
[Bug c/20382] New: internal compiler error in emit_move_insn, at expr.c:2809
systemConfig/5xx_board_init.c:104 internal compiler error: in emit_move_insn, at expr.c:2809 gcc version 3.4.0-macraigor1 GNU C version 3.4.0-macraigor1 (powerpc-elf) compiled by GNU C version 3.3.1 (cygming special). I didn't configure GNU, Macraigor did, I didn't even know one could configure it, I haven't seen documentation on this. command line is in file bug.rpt I don't see how to attach the files you have asked for: I'm running GNU on a Dell 8400 with WindowsXP and cygwin. -- Summary: internal compiler error in emit_move_insn, at expr.c:2809 Product: gcc Version: 3.4.1 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sailors3 at comcast dot net CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: 3.3.1-macraigor1 GCC host triplet: 3.4.0 GCC target triplet: 3.3.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20382
[Bug rtl-optimization/20367] alias analysis doesn't take into account that variables that haven't their address taken can't alias arbitrary MEMs
--- Additional Comments From giovannibajo at libero dot it 2005-03-08 12:30 --- So, to recap: testcase in comment #5 should not be optimized (at least, it is not related to this bug). Testcase in comment #2 is already optimized correctly in the tree-profiling-branch, which is due to be merged for 4.1. If so, we can suspend this bug until the branch is merged. The proposed patch cannot be merged to release branches because this is not a regression, AFAICT. I also guess that on the mainline we want to fix this at the tree level. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20367
[Bug c++/20381] ICE in build_ptrmemfunc, at cp/typeck.c:5702
-- What|Removed |Added CC||martin at mpa-garching dot ||mpg dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20381
[Bug c++/20381] ICE in build_ptrmemfunc, at cp/typeck.c:5702
--- Additional Comments From martin at mpa-garching dot mpg dot de
2005-03-08 12:19 ---
Here is a shorter testcase:
class foo {
public:
int f1(int);
};
template class bar: public foo {
void baz () {
&foo::f1;
}
};
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20381
[Bug other/17652] [meta-bug] GCC 4.1 pending patches
-- Bug 17652 depends on bug 18836, which changed state. Bug 18836 Summary: [4.1] target fold_builtin for alpha http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18836 What|Old Value |New Value Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17652
[Bug target/18836] [4.1] target fold_builtin for alpha
--- Additional Comments From rth at gcc dot gnu dot org 2005-03-08 12:02 --- Committed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18836
Re: Rq4Clarification: std::uncaught_exception
Please let me know where should I report this bug! Unsurprisingly, I suggest: http://gcc.gnu.org/bugzilla/ *Please* strive to reduce the relevant testcase as much as possible. Thanks, Paolo.
[Bug ada/20035] failed run-time assertion : Tasking not implemented on this configuration on sparc-linux
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-08 11:48 --- Subject: Bug 20035 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-03-08 11:48:35 Modified files: gcc/ada: ChangeLog Makefile.in Added files: gcc/ada: system-linux-sparc.ads Log message: 2005-03-07 James A. Morrison <[EMAIL PROTECTED]> Laurent Guerby <[EMAIL PROTECTED]> PR ada/20035 * system-linux-sparc.ads: New. * Makefile.in: Add sparc linux entry. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ada/system-linux-sparc.ads.diff?cvsroot=gcc&r1=1.1&r2=1.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ada/ChangeLog.diff?cvsroot=gcc&r1=1.640&r2=1.641 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ada/Makefile.in.diff?cvsroot=gcc&r1=1.111&r2=1.112 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20035
[Bug ada/20035] failed run-time assertion : Tasking not implemented on this configuration on sparc-linux
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-08 11:44 --- Subject: Bug 20035 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-03-08 11:44:40 Modified files: gcc/ada: ChangeLog Makefile.in Added files: gcc/ada: system-linux-sparc.ads Log message: 2005-03-07 James A. Morrison <[EMAIL PROTECTED]> Laurent Guerby <[EMAIL PROTECTED]> PR ada/20035 * system-linux-sparc.ads: New. * Makefile.in: Add sparc linux entry. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ada/system-linux-sparc.ads.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ada/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.638&r2=1.638.4.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ada/Makefile.in.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.110&r2=1.110.6.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20035
