[Bug fortran/27411] crashes in sra_walk_expr and emit_move_insn
--- Comment #3 from paul dot thomas at jet dot uk 2006-05-05 06:26 ---
The patch below fixes the problem by enclosing the expression for the array
reference outputs%signal_number in parentheses(You can verify that this does
the right thing by doing it explicitly in the fortran.). This turns the
temporary, used in the scalarizer loop, from the structure into its integer
component, signal_number. I did contemplate doing clever stuff with tree_ssa,
a bit further down stream, but this is much simpler and works.
I will do all the good things with assigning this PR to myself and submitting
the patch, when I am back at base.
Richard, which email address do you prefer in the attribution to you, in the
testscase?
Paul
Index: gcc/fortran/matchexp.c
===
--- gcc/fortran/matchexp.c (révision 113499)
+++ gcc/fortran/matchexp.c (copie de travail)
@@ -123,6 +123,26 @@
}
+/* Call the INTRINSIC_PARENTHESES function. This is both
+ used explicitly, as below, or by resolve.c to generate
+ temporaries. */
+gfc_expr *
+gfc_get_parentheses (gfc_expr *e)
+{
+ gfc_expr *e2;
+
+ e2 = gfc_get_expr();
+ e2-expr_type = EXPR_OP;
+ e2-ts = e-ts;
+ e2-rank = e-rank;
+ e2-where = e-where;
+ e2-value.op.operator = INTRINSIC_PARENTHESES;
+ e2-value.op.op1 = e;
+ e2-value.op.op2 = NULL;
+ return e2;
+}
+
+
/* Match a primary expression. */
static match
@@ -167,19 +187,8 @@
if(!gfc_numeric_ts(e-ts))
*result = e;
else
-{
- gfc_expr *e2 = gfc_get_expr();
+*result = gfc_get_parentheses (e);
- e2-expr_type = EXPR_OP;
- e2-ts = e-ts;
- e2-rank = e-rank;
- e2-where = where;
- e2-value.op.operator = INTRINSIC_PARENTHESES;
- e2-value.op.op1 = e;
- e2-value.op.op2 = NULL;
- *result = e2;
-}
-
if (m != MATCH_YES)
{
gfc_free_expr (*result);
Index: gcc/fortran/gfortran.h
===
--- gcc/fortran/gfortran.h (révision 113499)
+++ gcc/fortran/gfortran.h (copie de travail)
@@ -1940,6 +1940,9 @@
void gfc_free_data (gfc_data *);
void gfc_free_case_list (gfc_case *);
+/* matchexp.c -- FIXME too? */
+gfc_expr *gfc_get_parentheses (gfc_expr *);
+
/* openmp.c */
void gfc_free_omp_clauses (gfc_omp_clauses *);
void gfc_resolve_omp_directive (gfc_code *, gfc_namespace *);
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (révision 113499)
+++ gcc/fortran/resolve.c (copie de travail)
@@ -2284,6 +2284,7 @@
resolve_array_ref (gfc_array_ref * ar)
{
int i, check_scalar;
+ gfc_expr *e;
for (i = 0; i ar-dimen; i++)
{
@@ -2295,9 +2296,11 @@
return FAILURE;
if (gfc_resolve_index (ar-stride[i], check_scalar) == FAILURE)
return FAILURE;
+
+ e = ar-start[i];
if (ar-dimen_type[i] == DIMEN_UNKNOWN)
- switch (ar-start[i]-rank)
+ switch (e-rank)
{
case 0:
ar-dimen_type[i] = DIMEN_ELEMENT;
@@ -2305,11 +2308,15 @@
case 1:
ar-dimen_type[i] = DIMEN_VECTOR;
+ if (e-expr_type == EXPR_VARIABLE
+ e-symtree-n.sym-ts.type == BT_DERIVED)
+ ar-start[i] = gfc_get_parentheses (e);
+
break;
default:
gfc_error (Array index at %L is an array of rank %d,
- ar-c_where[i], ar-start[i]-rank);
+ ar-c_where[i], e-rank);
return FAILURE;
}
}
@@ -4363,6 +4370,7 @@
code-loc);
break;
}
+
goto call;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27411
[Bug other/14251] Use POSIX-compatible flags for 'head' and 'tail'
--- Comment #21 from eggert at gnu dot org 2006-05-05 06:54 --- Created an attachment (id=11381) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11381action=view) port GCC to 'sort' and 'tail' that use POSIX syntax This patch (originally reported in Bug 27434) ports the GCC build procedure to hosts (like mine) whose 'sort' and 'tail' implementations treat operands with leading '+' as file names, as POSIX has required since 2001. The patch doesn't affect the build procedure on traditional hosts that don't support POSIX syntax. This follows up on the recent gcc-patches discussion on this topic. In http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00179.html, Mike Stump writes that he's fine with the change. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14251
[Bug fortran/27304] gfortran: Warn/abort when format in write does not fit passed arguments
--- Comment #17 from fxcoudert at gcc dot gnu dot org 2006-05-05 07:04
---
(In reply to comment #15)
I probably do something wrong, but with
GNU Fortran 95 (GCC) 4.2.0 20060504 (experimental)
from http://quatramaran.ens.fr/~coudert/gfortran/gfortran-x86_64-linux.tar.gz
I still don't get a run-time error message.
Using fmt_exhaust.f90 it crashes (abort()) rather than going to 10 (err=10).
As does my test case.
With this exact same package, fmt_exhaust.f90 runs fines (all my nightly builds
are tested, and the results for this one:
http://quatramaran.ens.fr/~coudert/gfortran/test-results/test-x86_64-linux-20060504.log
are completely clean) and your testcase gives:
$ cat a.f90
program test
implicit none
integer :: n
n = 1
write(*,'(''n'')') n
end program test
$ ./bin/gfortran -static a.f90 ./a.out
At line 5 of file a.f90
Fortran runtime error: Insufficient data descriptors in format after reversion
This looks like you have an old version of the library around, and that it's
used instead of that of the newer compiler. Try compiling with -static or
setting LD_LIBRARY_PATH before execution.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu dot
||org
Status|REOPENED|WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27304
[Bug objc/27438] [4.1/4.2 Regression] '_OBJC_INSTANCE_0' defined but not used warning (unit at a time)
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-05-05 07:06 ---
Small testcase with the GNU runtime:
@interface NXConstantString
{
void *isa;
const char * const nxcsptr;
const unsigned int nxcslen;
}
@end
NXConstantString *a = @NSInconsistentArchiveException;
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
GCC build triplet|sparc-sun-solaris2.8|
GCC host triplet|sparc-sun-solaris2.8|
GCC target triplet|sparc-sun-solaris2.8|
Keywords||diagnostic
Known to fail||4.1.0 4.2.0
Known to work||4.0.0
Last reconfirmed|-00-00 00:00:00 |2006-05-05 07:06:12
date||
Summary|'_OBJC_INSTANCE_0' defined |[4.1/4.2 Regression]
|but not used warning (unit |'_OBJC_INSTANCE_0' defined
|at a time) |but not used warning (unit
||at a time)
Target Milestone|--- |4.1.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27438
[Bug fortran/20248] gfortran: intrinsics and std=f95, inconsistency with other compilers
--- Comment #12 from anlauf at gmx dot de 2006-05-05 07:09 --- (In reply to comment #11) I've looked at the problem. The -Wall option will set the -Wnonstd-intrinsic option. This flag appears to trigger a warning when used with -pedantic. It does not trigger a warning if you use it with just -std=f95. I am getting rather confused now. I would like to compile code that (with regard to language) is mostly strict Fortran 95 *except* using the rather common intrinsic extensions iargc and getarg. Therefore I use -std=f95 -Wall, but not -pedantic, because I also use other people's code that I do not want to fix. If something does not strictly adhere to the standard, getting a warning is fine, but stopping with an error is annoying. (This is how I used g77 and why I liked it very much. Easy to handle.) BTW: I just checked -Wnonstd-intrinsics (did not know about it before) and found that I cannot turn it off by using -Wno-nonstd-intrinsics. I guess that this is a bug. Back to your suggestion: I have a patch that will turn this back into a warning. Will this make you happy? troutmask:sgk[255] gfc4x -std=f95 -fall-intrinsics -Wnonstd-intrinsics -o z iargc.f90 In file iargc.f90:5 print *, iargc() 1 Warning: Intrinsic 'iargc' at (1) is not included in the selected standard troutmask:sgk[256] ./z 2 1 Any chance that -std=f95 -Wall -fall-intrinsics could do the same, maybe (*cough*) without (*cough*) a warning, needless to say an error? If I want a warning even with -fall-intrinsics, I would turn it on again with -Wnonstd-intrinsics. Cheers, -ha -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20248
[Bug fortran/27436] gfortran: Abort compiling if there are insufficient data descriptors in format after reversion
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2006-05-05 07:10
---
(In reply to comment #0)
Currently, gfortran only detects that the IO format descriptor contains
insufficient data at run time. It would be great (though of low priority) if
it would find them at compile time.
Indeed.
write(*,'(abc)') n
That one we could diagnose.
write(10,(i7,(' abcd')), err=10) n, n
This one, however, is not expected to give a warning since an err= specifier is
present. It's true we could optimize it away as a goto 10, but I think that
is low priority :)
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2006-05-05 07:10:05
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27436
[Bug java/27439] gcj chokes on invalid expression
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-05 07:11 --- Confirmed, related to PR 8923. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||8923 Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-05-05 07:11:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27439
[Bug middle-end/27095] [4.1 Regression] O2 produces duplicate code
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-05-05 07:20 --- I should note that this testcase fails on darwin because strlen is mentioned twice in the testcase as there is a stub for strlen. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27095
[Bug c++/27423] ICE on default argument for void parameter
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-05-05 07:23 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-05-05 07:23:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27423
[Bug c++/27427] [4.0/4.1/4.2 regression] ICE with invalid template parameter
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-05 07:24 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-05-05 07:24:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27427
[Bug objc/27438] [4.1/4.2 Regression] '_OBJC_INSTANCE_0' defined but not used warning (unit at a time)
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-05-05 07:31 --- (In reply to comment #4) Small testcase with the GNU runtime: Note only -Wall -funit-at-a-time is enough to reproduce the bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27438
[Bug objc/27377] [4.1/4.2 Regression] false compiler warnings generated in Objective-C code
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-05 08:01 ---
Confirmed, reduced testcase:
#include objc/Object.h
@interface NSObject
-lock;
@end
static NSObject *local_lock = (id)0;
void GSSetupEncodingTable(id t)
{
[(local_lock != (id)0 ? local_lock : t) lock];
}
For 4.0 and above you can remove the include. And this happens with the next
runtime also.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
GCC host triplet|amd64-unknown-freebsd7.0|
Keywords||diagnostic
Known to fail||4.1.0 4.2.0
Known to work||4.0.0
Last reconfirmed|-00-00 00:00:00 |2006-05-05 08:01:46
date||
Summary|false compiler warnings |[4.1/4.2 Regression] false
|generated in Objective-C|compiler warnings generated
|code|in Objective-C code
Target Milestone|--- |4.1.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27377
[Bug middle-end/25776] [4.2 Regression] ICE in cgraph after error at -O1 and above
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-05-05 08:11 --- Mine. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25776
[Bug middle-end/27428] [4.0/4.1/4.2 regression] ICE with goto in erroneous code
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-05 08:19 ---
In .orginal:
goto L;
if ( error )
{
L:;
}
In ,gimple:
foo ()
{
void L = error ;
goto L;
}
We really should keep the if (error_mark_node)
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2006-05-05 08:19:34
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27428
[Bug middle-end/27428] [4.0/4.1/4.2 regression] ICE with goto in erroneous code
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-05 08:32 ---
Comment out two lines in the gimplifier like:
Index: gimplify.c
===
--- gimplify.c (revision 113452)
+++ gimplify.c (working copy)
@@ -5655,8 +5655,8 @@ gimplify_expr (tree *expr_p, tree *pre_p
stub out the statement or propagate the error back out. */
if (ret == GS_ERROR)
{
- if (is_statement)
- *expr_p = NULL;
+ // if (is_statement)
+// *expr_p = NULL;
goto out;
}
Works but I don't know if there is any fall out from that because it is going
to be some.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27428
[Bug fortran/25681] [4.0 only] ICE with len of array of derived type
--- Comment #11 from fxcoudert at gcc dot gnu dot org 2006-05-05 09:00 --- Subject: Bug 25681 Author: fxcoudert Date: Fri May 5 09:00:25 2006 New Revision: 113551 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113551 Log: PR fortran/25681 * simplify.c (simplify_len): Character variables with constant length can be simplified. * gfortran.df/char_type_len.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/char_type_len.f90 - copied unchanged from r113376, trunk/gcc/testsuite/gfortran.dg/char_type_len.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/simplify.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25681
[Bug fortran/25681] ICE with len of array of derived type
--- Comment #12 from fxcoudert at gcc dot gnu dot org 2006-05-05 09:01 --- Fixed on mainline and 4.1. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED GCC build triplet|i686-pc-linux-gnu | GCC host triplet|i686-pc-linux-gnu | GCC target triplet|i686-pc-linux-gnu | Known to fail|4.1.1 | Known to work|4.2.0 | Resolution||FIXED Summary|[4.0 only] ICE with len of |ICE with len of array of |array of derived type |derived type Target Milestone|--- |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25681
[Bug tree-optimization/18031] OR of a bitfield and a constant is not optimized at tree level
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-05-05 09:13 ---
Here is a quick prototype addition for VRP, it does not handle the generic case
only [0, 1] | 1:
Index: tree-vrp.c
===
--- tree-vrp.c (revision 113452)
+++ tree-vrp.c (working copy)
@@ -1276,6 +1276,7 @@ extract_range_from_binary_expr (value_ra
code != MIN_EXPR
code != MAX_EXPR
code != BIT_AND_EXPR
+ code != BIT_IOR_EXPR
code != TRUTH_ANDIF_EXPR
code != TRUTH_ORIF_EXPR
code != TRUTH_AND_EXPR
@@ -1319,6 +1320,7 @@ extract_range_from_binary_expr (value_ra
the operands is VR_VARYING or symbolic range. TODO, we may be
able to derive anti-ranges in some cases. */
if (code != BIT_AND_EXPR
+ code != BIT_IOR_EXPR
code != TRUTH_AND_EXPR
code != TRUTH_OR_EXPR
(vr0.type == VR_VARYING
@@ -1568,6 +1570,27 @@ extract_range_from_binary_expr (value_ra
return;
}
}
+ else if (code == BIT_IOR_EXPR)
+{
+ /* FIXME. Handle only: [0, 1] | [1, 1], this should be expanded to
handle:
+ [ a, b ] | [b | b]. */
+ if (vr1.type == VR_RANGE
+ vr1.min == vr1.max
+ integer_onep (vr1.max)
+ vr0.type == VR_RANGE
+ integer_zerop (vr0.min)
+ integer_onep (vr0.max))
+ {
+ type = VR_RANGE;
+ min = build_int_cst (TREE_TYPE (expr), 1);
+ max = build_int_cst (TREE_TYPE (expr), 1);
+ }
+ else
+ {
+ set_value_range_to_varying (vr);
+ return;
+ }
+}
else
gcc_unreachable ();
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18031
[Bug tree-optimization/19792] Missed optimizations due to signedness in the way
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-05-05 09:17 --- the issue for foo might be considered a different harder issue to resolve. I think we need to decide what type is the argument for the ARRAY_REF, is it the type which the ARRAY has for its bounds or some other type? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19792
[Bug bootstrap/25672] cross build's libgcc picks up CFLAGS
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-05-05 09:19 --- (In reply to comment #6) nobody cares about this bad flags pickup? (In reply to comment #5) hmm, CFLAGS_FOR_TARGET picks up CFLAGS. Nobody else has ran into this and the patch was not posted to [EMAIL PROTECTED] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25672
[Bug c/27214] The C frontend introduces undefined pointer overflow
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-05-05 09:22 --- Maybe it is time to add POINTER_PLUS_EXPR which should solve the problem (well 95% of the way as what is the type of the 2nd operand, a signed or unsigned type). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27214
[Bug java/27442] New: gcj segfaults on invalid code (related to 8923?)
I'm not sure if this relates to Bug #8923, so I created a new bug report.
The following code causes gij to segfault:
class Bug
{
public void bug()
{
int x;
System.out.println((x 1).toString()); // segfault here
}
}
--
Summary: gcj segfaults on invalid code (related to 8923?)
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: brakhane at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27442
[Bug tree-optimization/27443] New: [4.2 regression] ICE at -O3 at hash_descriptor_pre_extension on entry_3.f90
The fortran testcase fortran-torture/execute/entry_3.f90 cannot compile as of 20060505 (but it worked on 20060504); see full testresults here: http://quatramaran.ens.fr/~coudert/gfortran/test-results/test-linux-20060505.log The backtrace is: Program received signal SIGSEGV, Segmentation fault. 0x08541c29 in hash_descriptor_pre_extension (p=0xbff3ad28) at ../../../trunk/gcc/see.c:837 837 rtx set = single_set (extension-se_insn); (gdb) where #0 0x08541c29 in hash_descriptor_pre_extension (p=0xbff3ad28) at ../../../trunk/gcc/see.c:837 #1 0x08595158 in htab_find_slot (htab=0x86e7868, element=0xbff3ad28, insert=INSERT) at ../../../trunk/libiberty/hashtab.c:657 #2 0x085429f6 in see_seek_pre_extension_expr (extension=0x0, type=DEF_EXTENSION) at ../../../trunk/gcc/see.c:1036 #3 0x08542b1c in see_set_prop_unmerged_def (slot=0x874fa08, b=0x874f958) at ../../../trunk/gcc/see.c:2280 #4 0x08594815 in htab_traverse_noresize (htab=0x874f978, callback=0x8542a70 see_set_prop_unmerged_def, info=0x874f958) at ../../../trunk/libiberty/hashtab.c:729 #5 0x085428e1 in see_handle_extensions_for_one_ref (stn=0x8720d70, data=0x0) at ../../../trunk/gcc/see.c:2986 #6 0x085959a9 in splay_tree_foreach_helper (sp=0x874f938, node=0x8720d70, fn=0x8542730 see_handle_extensions_for_one_ref, data=0x0) at ../../../trunk/libiberty/splay-tree.c:218 #7 0x08545322 in see_main () at ../../../trunk/gcc/see.c:3021 #8 0x08545a79 in rest_of_handle_see () at ../../../trunk/gcc/see.c:3754 #9 0x083c6878 in execute_one_pass (pass=0x8656f00) at ../../../trunk/gcc/passes.c:864 #10 0x083c6a1f in execute_pass_list (pass=0x8656f00) at ../../../trunk/gcc/passes.c:911 #11 0x083c6a32 in execute_pass_list (pass=0x8654e80) The file gcc/see.c was introduced by revision 113518 (http://gcc.gnu.org/viewcvs?rev=113518view=rev). I add the corresponding submitters and maintainers in CC of this PR. -- Summary: [4.2 regression] ICE at -O3 at hash_descriptor_pre_extension on entry_3.f90 Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org GCC build triplet: i686-linux GCC host triplet: i686-linux GCC target triplet: i686-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27443
[Bug libfortran/26985] incorrect matmul result
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-05-05 11:07 --- (In reply to comment #4) would you care to replace rystride == ycount with rystride == xcount as a fix for this, independent of the matmul BLAS issue? I think this is definitely worth it, especially for 4.1. Pre-approved if you do so :-) Commiting on mainline first, after regtesting on i686-linux and adding the corresponding testcase. I will commit on 4.1 branch in a few days. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26985
[Bug libfortran/26985] incorrect matmul result
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2006-05-05 11:08 --- Subject: Bug 26985 Author: fxcoudert Date: Fri May 5 11:08:23 2006 New Revision: 113552 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113552 Log: PR libfortran/26985 * m4/matmul.m4: Correct the condition for the memset call, and remove the unneeded call to size0. * generated/matmul_r4.c: Regenerate. * generated/matmul_r8.c: Regenerate. * generated/matmul_r10.c: Regenerate. * generated/matmul_r16.c: Regenerate. * generated/matmul_c4.c: Regenerate. * generated/matmul_c8.c: Regenerate. * generated/matmul_c10.c: Regenerate. * generated/matmul_c16.c: Regenerate. * generated/matmul_i4.c: Regenerate. * generated/matmul_i8.c: Regenerate. * generated/matmul_i16.c: Regenerate. * gfortran.dg/matmul_2.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/matmul_2.f90 Modified: trunk/gcc/testsuite/ChangeLog trunk/libgfortran/ChangeLog trunk/libgfortran/generated/matmul_c10.c trunk/libgfortran/generated/matmul_c16.c trunk/libgfortran/generated/matmul_c4.c trunk/libgfortran/generated/matmul_c8.c trunk/libgfortran/generated/matmul_i16.c trunk/libgfortran/generated/matmul_i4.c trunk/libgfortran/generated/matmul_i8.c trunk/libgfortran/generated/matmul_r10.c trunk/libgfortran/generated/matmul_r16.c trunk/libgfortran/generated/matmul_r4.c trunk/libgfortran/generated/matmul_r8.c trunk/libgfortran/m4/matmul.m4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26985
[Bug libfortran/27401] Bad overloaded operator selected
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-05-05 11:12 --- This is indeed fixed on 4.1 branch, that should be (soon?) released as 4.1.1. This was previously reported as bug #26716. *** This bug has been marked as a duplicate of 26716 *** -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27401
[Bug fortran/26716] [4.1/4.2 regression] gfortran: incorrect choice of overloaded function
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2006-05-05 11:12 --- *** Bug 27401 has been marked as a duplicate of this bug. *** -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||ajdiaz at connectical dot ||net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26716
[Bug bootstrap/25715] lack of gcc target headers inclusion.
--- Comment #1 from pluto at agmk dot net 2006-05-05 11:29 --- crossbuild of 4.1.1-20060504 (rev. 113515) for i686-ppc64 and x86-64-ppc64 works to me now. -- pluto at agmk dot net changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25715
[Bug bootstrap/25672] cross build's libgcc picks up CFLAGS
--- Comment #8 from pluto at agmk dot net 2006-05-05 11:52 --- patch posted: http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00204.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25672
[Bug tree-optimization/27335] [4.0/4.1/4.2 regression] ICE in get_loop_body
-- rakdver at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-04-30 05:55:08 |2006-05-05 12:16:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27335
[Bug debug/26881] [4.1/4.2 Regression] internal compiler error in dwarf2out_finish
--- Comment #9 from jakub at gcc dot gnu dot org 2006-05-05 12:26 --- For static variables in function contexts dwarf2out in several places wants to look up the parent context DIE. Now when the variables are registered with dwarf2out before the containing function, the parent context DIE doesn't exist yet. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26881
[Bug tree-optimization/27443] [4.2 regression] ICE at -O3 at hash_descriptor_pre_extension on entry_3.f90
--- Comment #1 from reichelt at gcc dot gnu dot org 2006-05-05 12:39 --- *** This bug has been marked as a duplicate of 27437 *** -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27443
[Bug rtl-optimization/27437] [4.2 Regression]: -O3 regression due to SEE
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-05-05 12:39 --- *** Bug 27443 has been marked as a duplicate of this bug. *** -- reichelt at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27437
[Bug rtl-optimization/27437] [4.2 Regression]: -O3 regression due to SEE
--- Comment #4 from reichelt at gcc dot gnu dot org 2006-05-05 12:41
---
Here's a testcase that crashes on x86_64-unknown-linux-gnu with -O3
or -O2 -fsee:
unsigned char foo(unsigned char i)
{
while (1 i)
--i;
return i;
}
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
CC||reichelt at gcc dot gnu dot
||org
Severity|normal |critical
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27437
[Bug rtl-optimization/27437] [4.2 Regression]: -O3 regression due to SEE
--- Comment #5 from hjl at lucon dot org 2006-05-05 13:01 ---
There are several problems with the current SEE implementation:
1. SEE uses NEXT_INSN/PREV_INSN to find adjacent insns to check if SEE
is safe. But with -g, NEXT_INSN/PREV_INSN may point to a NOTE:
(note:HI 17 14 18 2
(/net/gnu-13/export/gnu/src/gcc-see/gcc/gcc/testsuite/gcc.c-torture/execute/20010224-1.c)
18)
(insn:HI 18 17 19 2
/net/gnu-13/export/gnu/src/gcc-see/gcc/gcc/testsuite/gcc.c-torture/execute/20010224-1.c:18
(set (reg/v:SI 70 [ j ])
(sign_extend:SI (subreg:HI (reg:SI 72 [ start ]) 0))) 118 {extendhisi2}
(insn_list:REG_DEP_TRUE 12 (nil))
(expr_list:REG_DEAD (reg:SI 72 [ start ])
(nil)))
(note:HI 19 18 20 2
(/net/gnu-13/export/gnu/src/gcc-see/gcc/gcc/testsuite/gcc.c-torture/execute/20010224-1.c)
19)
(insn:HI 20 19 22 2
/net/gnu-13/export/gnu/src/gcc-see/gcc/gcc/testsuite/gcc.c-torture/execute/20010224-1.c:19
(set (reg:DI 73 [ j ])
(sign_extend:DI (reg/v:SI 70 [ j ]))) 115 {extendsidi2_rex64}
(insn_list:REG_DEP_TRUE 18 (nil))
(nil))
Those notes may be added between insns because -g. NEXT_INSN/PREV_INSN
won't get you the adjacent insn in this case.
2. Not all zero_extend patterns are available for x86/x86-64. For
example:
(insn 137 0 0 (set (reg:SI 60 [ prephitmp.115 ])
(zero_extend:SI (subreg:QI (reg:SI 60 [ prephitmp.115 ]) 0)))
-1 (nil)
(nil))
may not be used on x86/x86-64. i386.md has
(define_expand zero_extendqisi2
[(parallel
[(set (match_operand:SI 0 register_operand )
(zero_extend:SI (match_operand:QI 1 nonimmediate_operand )))
(clobber (reg:CC FLAGS_REG))])]
)
This is case for all extensions for i386. For x86-64, only
zero_extendsidi2 won't clobber CC. But SEE doesn't provide a way for a backend
to deal with it.
3. When the original insns were
set (dest_extension_reg1) (sign_extend (source_extension_reg1))
set (dest_extension_reg2) (sign_extend (dest_extension_reg1))
We created
ref: set (dest_extension_reg1) (sign_extend (source_extension_reg1))
def_se: set (dest_extension_reg2) (sign_extend (dest_extension_reg1))
and
use_se: set (dest_extension_reg1) (sign_extend (dest_extension_reg1))
ref: set (dest_extension_reg2) (sign_extend (dest_extension_reg1))
When def merge failed, def_se was deleted. Now use_se had a deleted
ref.
Basically, SEE doesn't handle
(set (reg/v:SI 70 [ j ])
(sign_extend:SI (subreg:HI (reg:SI 72 [ start ]) 0)))
(set (reg:DI 73 [ j ])
(sign_extend:DI (reg/v:SI 70 [ j ])))
correctly.
4. SEE also failed to handle
set (dest_extension_reg1) (zero_extend (source_extension_reg1))
set (reg) (..dest_extension_reg1..)
set (dest_extension_reg2) (sign_extend (source_extension_reg1))
(insn:HI 28 26 30 2 x.c:1201 (set (reg:DI 534 [ mode ])
(zero_extend:DI (reg/v:SI 264 [ mode ]))) 111
{zero_extendsidi2_rex64}
(insn_list:REG_DEP_TRUE 11 (nil))
(nil))
(insn:HI 30 28 269 2 x.c:1201 (set (reg:QI 261 [ D.24257 ])
(mem/s/u:QI (plus:DI (reg:DI 534 [ mode ])
(symbol_ref:DI (mode_class) [flags 0x40] var_decl
0x2a98a42630 mode_class)) [0 mode_class S1 A8])) 55 {*movqi_1}
(insn_list:REG_DEP_TRUE 28 (nil))
(nil))
(insn:HI 269 30 270 2 x.c:1273 (set (reg:DI 546)
(sign_extend:DI (reg/v:SI 264 [ mode ]))) 115
{extendsidi2_rex64} (nil)
(nil))
#3 and #4 may happen since SEE uses NEXT_INSN/PREV_INSN to check
the adjacent insn. When -g is used, SEE may see the note instead of
the real adjacent insn and reaches wrong conclusion. It may lead to
compiler crash or wrong code.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27437
[Bug target/27440] [4.0/4.1/4.2 regression] code quality regression due to ivopts
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-05-05 13:10 --- Yes it does. Not that the outcome is optimal here... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27440
[Bug fortran/20248] gfortran: intrinsics and std=f95, inconsistency with other compilers
--- Comment #13 from sgk at troutmask dot apl dot washington dot edu 2006-05-05 14:25 --- Subject: Re: gfortran: intrinsics and std=f95, inconsistency with other compilers On Fri, May 05, 2006 at 07:09:37AM -, anlauf at gmx dot de wrote: --- Comment #12 from anlauf at gmx dot de 2006-05-05 07:09 --- (In reply to comment #11) I've looked at the problem. The -Wall option will set the -Wnonstd-intrinsic option. This flag appears to trigger a warning when used with -pedantic. It does not trigger a warning if you use it with just -std=f95. I am getting rather confused now. You're not the only one. :) gfortran is growing a rather large set of options and checking the interaction among them is a pain. BTW: I just checked -Wnonstd-intrinsics (did not know about it before) and found that I cannot turn it off by using -Wno-nonstd-intrinsics. I guess that this is a bug. I would need to look at options.c to see how the flag is set. I'm surprise that the no- form isn't available. troutmask:sgk[255] gfc4x -std=f95 -fall-intrinsics -Wnonstd-intrinsics -o z iargc.f90 In file iargc.f90:5 print *, iargc() 1 Warning: Intrinsic 'iargc' at (1) is not included in the selected standard troutmask:sgk[256] ./z 2 Any chance that -std=f95 -Wall -fall-intrinsics could do the same, maybe (*cough*) without (*cough*) a warning, needless to say an error? Sure. I can make it do this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20248
[Bug rtl-optimization/27437] [4.2 Regression]: -O3 regression due to SEE
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-05-05 15:04 --- (In reply to comment #5) There are several problems with the current SEE implementation: 1. SEE uses NEXT_INSN/PREV_INSN to find adjacent insns to check if SEE is safe. But with -g, NEXT_INSN/PREV_INSN may point to a NOTE: That one is easy to fix. Please post a patch to using next_nonnote_insn/prev_nonnote_insn instead. And then the -O3 (without -g) is a different issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27437
[Bug libgcj/27294] gij throws NullPointerException, when the interpreter is not enabled
--- Comment #2 from tromey at gcc dot gnu dot org 2006-05-05 15:05 --- Subject: Bug 27294 Author: tromey Date: Fri May 5 15:05:20 2006 New Revision: 113554 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113554 Log: PR libgcj/27294: * java/lang/natVMClassLoader.cc (defineClass): Throw VirtualMachineError if no interpreter configured. Modified: trunk/libjava/ChangeLog trunk/libjava/java/lang/natVMClassLoader.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27294
[Bug libgcj/27294] gij throws NullPointerException, when the interpreter is not enabled
--- Comment #3 from tromey at gcc dot gnu dot org 2006-05-05 15:06 --- Now we print something nicer: opsy. gij t Exception in thread main java.lang.VirtualMachineError: found class file for class t, but no interpreter configured in this libgcj -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27294
[Bug other/27417] wrong code or aliasing violation with missed diagnostic?
--- Comment #4 from pluto at agmk dot net 2006-05-05 15:10 --- (In reply to comment #3) You cannot. Though you can try extending c-common.c:strict_aliasing_warning and cp/typeck.c:build_reinterpret_cast_1 to warn in this case. sorry, but i don't know compiler internals to do this. btw, maybe we should collect in one PR examples of undetected aliasing violations for future work on better detection? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27417
[Bug c++/27424] [4.0/4.1/4.2 regression] Valid template-template-parameter rejected
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-05 15:30 --- This looks very much related to PR 27403 which also looks very valid. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-05-05 15:30:07 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27424
[Bug c++/27425] [4.0/4.1/4.2 regression] ICE with invalid template-template-parameter
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-05 15:44 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-05-05 15:44:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27425
[Bug rtl-optimization/27437] [4.2 Regression]: -O3 regression due to SEE
-- hjl at lucon dot org changed: What|Removed |Added CC||denis dot nagorny at intel ||dot com Severity|critical|normal Target Milestone|4.2.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27437
[Bug rtl-optimization/27437] [4.2 Regression]: -O3 regression due to SEE
--- Comment #7 from hjl at lucon dot org 2006-05-05 15:49 --- (In reply to comment #6) (In reply to comment #5) There are several problems with the current SEE implementation: 1. SEE uses NEXT_INSN/PREV_INSN to find adjacent insns to check if SEE is safe. But with -g, NEXT_INSN/PREV_INSN may point to a NOTE: That one is easy to fix. Please post a patch to using next_nonnote_insn/prev_nonnote_insn instead. And then the -O3 (without -g) is a different issue. You are right. Using next_nonnote_insn/prev_nonnote_insn won't solve -O3 (without -g). One real problem is SEE can't determine if SEE is safe by just looking at next_nonnote_insn/prev_nonnote_insn. The relevant insn may be a few more insns away. Denis, do you have a patch to address this? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27437
[Bug tree-optimization/23744] VRP does not merge discontinuous ranges of PHIs
--- Comment #6 from patchapp at dberlin dot org 2006-05-05 15:55 --- Subject: Bug number PR23744 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00200.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23744
[Bug c/27445] New: create_tmp_var_raw (gimplify.c) inadventently asserts 'volatile' on temps
(see also: http://gcc.gnu.org/ml/gcc/2006-05/msg00158.html)
While following GCC's handling of 'volatile' and other type
qualifiers, I noticed that the gimplify pass created temporaries
with a type with 'volatile' asserted if the underlying type also
had 'volatile' asserted.
Temporaries are created by the create_tmp_var_raw() procedure
in gimplify.c, which reads as follows:
tree
create_tmp_var_raw (tree type, const char *prefix)
{
tree tmp_var;
tree new_type;
/* Make the type of the variable writable. */
new_type = build_type_variant (type, 0, 0);
TYPE_ATTRIBUTES (new_type) = TYPE_ATTRIBUTES (type);
tmp_var = build_decl (VAR_DECL, prefix ? create_tmp_var_name (prefix) :
NULL,
type);
[...]
Note above that an unqualified type, new_type, is created but
then subsequently not used in the call to build_decl. Because of
this omission, if 'type' originally had any qualifiers set
(such as volatile), they'll be propagated to the temporary, which
might have some unexpected effects on subsequent optimizations
and code generation.
The fix, I think, is to pass 'new_type'.
--
Summary: create_tmp_var_raw (gimplify.c) inadventently asserts
'volatile' on temps
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gary at intrepid dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27445
[Bug c/27445] create_tmp_var_raw (gimplify.c) inadventently asserts 'volatile' on temps
--- Comment #2 from gary at intrepid dot com 2006-05-05 16:06 --- Created an attachment (id=11382) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11382action=view) create_tmp_var_raw patch: remove type qualifiers This patch compiles, but hasn't been tested. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27445
[Bug c/27445] create_tmp_var_raw (gimplify.c) inadventently asserts 'volatile' on temps
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-05 16:04 --- Do you have a testcase this will better understand the problem and to see if your patch is correct? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27445
[Bug c/27445] create_tmp_var_raw (gimplify.c) inadventently asserts 'volatile' on temps
--- Comment #3 from gary at intrepid dot com 2006-05-05 16:12 --- (In reply to comment #1) Do you have a testcase this will better understand the problem and to see if your patch is correct? I'm not sure how to demonstrate that there is a problem. I think it is clear that the author of the function planned on using new_type instaed of type, and that it is incorrect to assert 'volatile' on a compiler temporary, but am uncertain as to whether asserting 'volatile' leads to any particular difficulties in the present compiler. I'm hoping one of the gimplify developers can help construct a test case, if applicable. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27445
[Bug middle-end/27445] create_tmp_var_raw (gimplify.c) inadventently asserts 'volatile' on temps
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-05-05 16:16 --- Then the real question is why do you think this is a bug? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27445
[Bug fortran/27446] New: ICE on OpenMP array REDUCTION clause and -fbounds-check
This bug is linked to PR27395 because the same 2 fortran test cases are the ones triggering the problem. (The test cases can be found further bellow or as their equivalents PR27395_1.f90 and PR27395_2.f90 in the libgomp dejagnu testsuite) Once PR27395 was corrected (Thanks Jakub) I played around with compile options. adding the -fbounds-check options triggers the following ICE for both testcases gfortran -v Using built-in specs. Target: i386-linux Configured with: ../gcc/configure --prefix=/cosmic/coudert/tmp/gfortran-20060504/irun --enable-languages=c,fortran --host=i386-linux --with-gmp=/cosmic/coudert/tmp/gfortran-20060504/gfortran_libs Thread model: posix gcc version 4.2.0 20060504 (experimental) gfortran -fopenmp -fbounds-check array_reduction1.f90 array_reduction1.f90: In function 'foo1': array_reduction1.f90:24: internal compiler error: in declare_tmp_vars, at gimplify.c:661 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. gfortran -fopenmp -fbounds-check array_reduction2.f90 array_reduction2.f90: In function 'foo2': array_reduction2.f90:20: internal compiler error: in declare_tmp_vars, at gimplify.c:661 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. more array_reduction1 program array_reduction1 implicit none integer, parameter :: n=10,m=1000 integer :: i integer, dimension(n) :: sumarray ! call foo1(n,m,sumarray) do i=1,n print*,sumarray(i) end do end program array_reduction1 subroutine foo1(n,m,sumarray) use omp_lib, only : omp_get_thread_num implicit none integer, intent(in) :: n,m integer, dimension(n), intent(out) :: sumarray ! integer :: i,j ! sumarray(:)=0 !$OMP PARALLEL DEFAULT(shared) print*,'hello from thread ',omp_get_thread_num() !$OMP DO PRIVATE(j,i), REDUCTION(+:sumarray) do j=1,m do i=1,n sumarray(i)=sumarray(i)+i end do end do !$OMP END DO !$OMP END PARALLEL end subroutine foo --- more array_reduction2.f90 program array_reduction2 implicit none integer, parameter :: n=10,m=1000 integer :: i ! call foo2(n,m) end program array_reduction2 subroutine foo2(n,m) use omp_lib, only : omp_get_thread_num implicit none integer, intent(in) :: n,m ! integer :: i,j integer, dimension(n) :: sumarray ! sumarray(:)=0 !$OMP PARALLEL DEFAULT(shared) print*,'hello from thread ',omp_get_thread_num() !$OMP DO PRIVATE(j,i), REDUCTION(+:sumarray) do j=1,m do i=1,n sumarray(i)=sumarray(i)+i end do end do !$OMP END DO !$OMP END PARALLEL do i=1,n print*,sumarray(i) end do end subroutine foo2 Routines are added again here for completeness -- Summary: ICE on OpenMP array REDUCTION clause and -fbounds-check Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: benjamin dot reveille at gmail dot com GCC build triplet: i386-gnu-linux GCC host triplet: i386-gnu-linux GCC target triplet: i386-gnu-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27446
[Bug middle-end/27445] create_tmp_var_raw (gimplify.c) inadventently asserts 'volatile' on temps
--- Comment #5 from gary at intrepid dot com 2006-05-05 16:37 --- (In reply to comment #4) Then the real question is why do you think this is a bug? 1. it is a bug to create temporaries and assert 'volatile' on them 2. there is code in create_tmp_var_raw() that creates a type with qualifiers removed, but this new_type is then not used at the moment. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27445
Re: [Bug middle-end/27445] create_tmp_var_raw (gimplify.c) inadventently asserts 'volatile' on temps
--- Comment #5 from gary at intrepid dot com 2006-05-05 16:37 --- (In reply to comment #4) Then the real question is why do you think this is a bug? 1. it is a bug to create temporaries and assert 'volatile' on them Why do you say that? 2. there is code in create_tmp_var_raw() that creates a type with qualifiers removed, but this new_type is then not used at the moment. I don't think create_tmp_var_raw should remove the quals. -- Pinski
[Bug middle-end/27445] create_tmp_var_raw (gimplify.c) inadventently asserts 'volatile' on temps
--- Comment #6 from pinskia at physics dot uc dot edu 2006-05-05 16:39 --- Subject: Re: create_tmp_var_raw (gimplify.c) inadventently asserts 'volatile' on temps --- Comment #5 from gary at intrepid dot com 2006-05-05 16:37 --- (In reply to comment #4) Then the real question is why do you think this is a bug? 1. it is a bug to create temporaries and assert 'volatile' on them Why do you say that? 2. there is code in create_tmp_var_raw() that creates a type with qualifiers removed, but this new_type is then not used at the moment. I don't think create_tmp_var_raw should remove the quals. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27445
[Bug c++/27447] New: [4.1/4.2 regression] ICE on invalid ptr-to-member-function
The following invalid testcase triggers an ICE since GCC 4.1.0: void (A::* p)(); bug.cc:1: error: 'A' has not been declared bug.cc:1: internal compiler error: tree check: expected class 'type', have 'exceptional' (error_mark) in build_method_type_directly, at tree.c:5172 Please submit a full bug report, [etc.] -- Summary: [4.1/4.2 regression] ICE on invalid ptr-to-member- function Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code, error-recovery, monitored Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: reichelt at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27447
[Bug c++/27447] [4.1/4.2 regression] ICE on invalid ptr-to-member-function
--- Comment #1 from reichelt at gcc dot gnu dot org 2006-05-05 16:44 --- Testing a patch. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |reichelt at gcc dot gnu dot |dot org |org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27447
[Bug c++/27447] [4.1/4.2 regression] ICE on invalid ptr-to-member-function
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-05 16:45 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-05-05 16:45:29 date|| Target Milestone|--- |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27447
[Bug rtl-optimization/27437] [4.2 Regression] -O3 regression due to SEE
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-05-05 16:49 --- (In reply to comment #7) You are right. Using next_nonnote_insn/prev_nonnote_insn won't solve -O3 (without -g). One real problem is SEE can't determine if SEE is safe by just looking at next_nonnote_insn/prev_nonnote_insn. The relevant insn may be a few more insns away. Denis, do you have a patch to address this? Maybe the real question is why did you not raise this publicly when it was being reviewed. Your terse style of reporting problems after the fact hurt your crediablity (if there is any left now). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||ice-on-valid-code Summary|[4.2 Regression]: -O3 |[4.2 Regression] -O3 |regression due to SEE |regression due to SEE Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27437
[Bug middle-end/27445] create_tmp_var_raw (gimplify.c) inadventently asserts 'volatile' on temps
--- Comment #7 from gary at intrepid dot com 2006-05-05 16:58 ---
Consider the following:
volatile int j;
void p()
{
++j;
}
Gimplify in its present form might transform the statement above into
something like the following:
volatile int j;
void p()
{
volatile int T1;
T1 = j + 1;
j = T1;
}
Here, gimplify has created a local temporary but has tagged it as
volatile, because j is volatile.
Taken literally, (j + 1) must be evaluated, and its value stored
into T1, and T1 must be a _memory_ location, not a register,
which looks like this on an x86:
movlj, %eax
addl$1, %eax
movl%eax, -4(%ebp)
movl-4(%ebp), %eax
movl%eax, j
Now as it turns out, somehow gimplify and the follow-on optimization
passes don't seem to target T1 into a memory location, probably because
they know that temporary variables for scalars should live in registers.
But still the compiler does create a temporary like T1 above and
qualifies T1 as volatile. The fact that subsequent passes seem to
ignore the qualifier is logically inconsistent, and at some level
incorrect. Will they always ignore that qualifier? Who can say?
Note also that at present const and restricted (on pointers)
can also be specified. Can't say if applying them to temporaries
causes any real harm, but again, it is logically inconsistent.
If we believe that gimplify should create trees that are well-formed
unambiguous and that precisely describe the semantics of the program
that is being translated, then I think the type qualifiers should be
dropped when declaring compiler temporaries.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27445
[Bug fortran/20248] gfortran: intrinsics and std=f95, inconsistency with other compilers
--- Comment #14 from sgk at troutmask dot apl dot washington dot edu 2006-05-05 17:09 --- Subject: Re: gfortran: intrinsics and std=f95, inconsistency with other compilers On Fri, May 05, 2006 at 07:09:37AM -, anlauf at gmx dot de wrote: Any chance that -std=f95 -Wall -fall-intrinsics could do the same, maybe (*cough*) without (*cough*) a warning, needless to say an error? If I want a warning even with -fall-intrinsics, I would turn it on again with -Wnonstd-intrinsics. Harald, How does this look to you? % gfc4x -o z -std=f95 iargc.f90 /home/sgk/tmp/ccSftiWA.o(.text+0x55): In function `MAIN__': : undefined reference to `iargc_' collect2: ld returned 1 exit status % gfc4x -o z -std=f95 -fall-intrinsics iargc.f90 % gfc4x -o z -std=f95 -fall-intrinsics -Wall iargc.f90 % gfc4x -o z -std=f95 -fall-intrinsics -Wnonstd-intrinsics iargc.f90 % gfc4x -o z -std=f95 -fall-intrinsics -Wno-nonstd-intrinsics iargc.f90 % gfc4x -o z -pedantic -Wno-nonstd-intrinsics iargc.f90 % gfc4x -o z -pedantic -Wnonstd-intrinsics iargc.f90 In file iargc.f90:5 print *, iargc() 1 Warning: Intrinsic 'iargc' at (1) is not included in the selected standard % gfc4x -o z -pedantic -Wall iargc.f90 In file iargc.f90:5 print *, iargc() 1 Warning: Intrinsic 'iargc' at (1) is not included in the selected standard -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20248
[Bug middle-end/27445] create_tmp_var_raw (gimplify.c) inadventently asserts 'volatile' on temps
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-05-05 17:10 ---
(In reply to comment #7)
Consider the following:
volatile int j;
void p()
{
++j;
}
Gimplify in its present form might transform the statement above into
something like the following:
It will never get the wrong type. because create_tmp_from_val uses
TYPE_MAIN_VARIANT.
Your issue with ++j not using incr is not related to the gimplifier at all as
it also happens in every compiler version since at least 2.95.3.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27445
[Bug tree-optimization/27448] New: simple openmp program segfaults compiler
Compiling the attached simple openmp program with gcc -fopenmp ... gives omp_hog.c: In function 'main': omp_hog.c:5: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. -- Summary: simple openmp program segfaults compiler Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ak at muc dot de GCC host triplet: x86_64-linux GCC target triplet: x86_64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27448
[Bug tree-optimization/27448] simple openmp program segfaults compiler
--- Comment #1 from ak at muc dot de 2006-05-05 17:17 --- Created an attachment (id=11383) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11383action=view) preprocessed test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27448
[Bug middle-end/27448] simple openmp program segfaults compiler
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-05 17:33 --- Interesting it does not fail on x86-linux-gnu -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27448
[Bug middle-end/27448] simple openmp program segfaults compiler
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-05-05 17:35 --- Or this was just fixed yesterday. Can you give the output of gcc -v? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27448
[Bug middle-end/27448] simple openmp program segfaults compiler
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-05-05 17:38 --- Also as of today this works on x86_64 also. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27448
[Bug middle-end/27445] create_tmp_var_raw (gimplify.c) inadventently asserts 'volatile' on temps
--- Comment #9 from gary at intrepid dot com 2006-05-05 17:55 ---
Your issue with ++j not using incr is not related to the gimplifier at all as
it also happens in every compiler version since at least 2.95.3.
I agree that is unrelated. I didn't file this bug thinking that it would help
fix the incr issue. In fact, I don't really have an incr issue -- it
was just something that came up while I was writing some tests.
Gimplify in its present form might transform the statement above into
something like the following:
[...]
It will never get the wrong type. because create_tmp_from_val uses
TYPE_MAIN_VARIANT.
Well, I originally noticed the problem in 4.0.1, which has the following
code:
static inline tree
create_tmp_from_val (tree val)
{
return create_tmp_var (TREE_TYPE (val), get_name (val));
}
The dev tree now how this code:
static inline tree
create_tmp_from_val (tree val)
{
return create_tmp_var (TYPE_MAIN_VARIANT (TREE_TYPE (val)), get_name (val));
}
I haven't looked into the rev. history, to see why/when this fix was made,
but will ask the hypothetical: was this fix made to workaround the
misbehavior in create_tmp_var_raw()? Note that create_tmp_var_raw()
is exported from gimplify.c and appears to be called from quite a few
places. The question arises: what are the preconditions for calling
create_tmp_var_raw()? If you want to assert that it uses whatever
type was passed in and all the callers have to remove qualifiers
as necessary that's fine, but requires some knowledge of the original
intent behind create_tmp_var_raw() and the assumptions its callers make.
I'd be temtpted to add an assert that the type passed in has no qualifiers
if that is a pre-condition.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27445
[Bug fortran/27449] New: transfer intrinsic does not work on strongly aligned systems
gfortran.dg/transfer_array_intrinsic_2.f90 fails on hppa64-hp-hpux11.11, I created a cut down test case and the cutdown test fails on hppa64-hp-hpux11.11 and ia64-hp-hpux11.23. On IA64 it fails in 32 and 64 bit modes. I think the problem is with alignment since the program is dying on an 8 byte load of a 4 byte aligned address. I looked at trans-intrinsic.c but was not able to exactly identify where the bad code was coming from. All the targets where I get the failure require 8 byte alignment of 8 byte loads. Test case: character(8) :: ch(1) = (/lmnoPQRS/) integer(8) :: ic(1) integer :: i = 1 integer :: q q = TRANSFER(i, q) ic = transfer (ch, ic) end -- Summary: transfer intrinsic does not work on strongly aligned systems Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sje at cup dot hp dot com GCC host triplet: hppa64-hp-hpux11.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27449
Re: [Bug middle-end/27445] create_tmp_var_raw (gimplify.c) inadventently asserts 'volatile' on temps
I haven't looked into the rev. history, to see why/when this fix was made, but will ask the hypothetical: was this fix made to workaround the misbehavior in create_tmp_var_raw()? Note that create_tmp_var_raw() is exported from gimplify.c and appears to be called from quite a few places. The question arises: what are the preconditions for calling create_tmp_var_raw()? If you want to assert that it uses whatever type was passed in and all the callers have to remove qualifiers as necessary that's fine, but requires some knowledge of the original intent behind create_tmp_var_raw() and the assumptions its callers make. I'd be temtpted to add an assert that the type passed in has no qualifiers if that is a pre-condition. Compiler temporaries we generate explicitly, have the same qualifiers as the expression they are generated from. This is by design.
[Bug middle-end/27445] create_tmp_var_raw (gimplify.c) inadventently asserts 'volatile' on temps
--- Comment #10 from dberlin at gcc dot gnu dot org 2006-05-05 18:06 --- Subject: Re: create_tmp_var_raw (gimplify.c) inadventently asserts 'volatile' on temps I haven't looked into the rev. history, to see why/when this fix was made, but will ask the hypothetical: was this fix made to workaround the misbehavior in create_tmp_var_raw()? Note that create_tmp_var_raw() is exported from gimplify.c and appears to be called from quite a few places. The question arises: what are the preconditions for calling create_tmp_var_raw()? If you want to assert that it uses whatever type was passed in and all the callers have to remove qualifiers as necessary that's fine, but requires some knowledge of the original intent behind create_tmp_var_raw() and the assumptions its callers make. I'd be temtpted to add an assert that the type passed in has no qualifiers if that is a pre-condition. Compiler temporaries we generate explicitly, have the same qualifiers as the expression they are generated from. This is by design. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27445
[Bug middle-end/27448] simple openmp program segfaults compiler
--- Comment #5 from ak at muc dot de 2006-05-05 18:13 --- I got a new gcc today before reporting /pkg/gcc-4.2/bin/gcc -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --prefix=/pkg/gcc-4.2-060409 --disable-checking --enable-languages=c,c++ --disable-nls Thread model: posix gcc version 4.2.0 20060409 (experimental) It doesn't work for me with that gcc. Maybe it's dependent on the host / OS release in some way. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27448
[Bug middle-end/27448] simple openmp program segfaults compiler
--- Comment #6 from ak at muc dot de 2006-05-05 18:14 --- Oops as you can see I indeed used an old gcc by mistake - a symlink was set wrong. With the current gcc it works. -- ak at muc dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27448
[Bug fortran/21130] 38822 lines of Fortran 90 takes more than 10 minutes to compile on a dual 3GHz P4 Linux box with lots of RAM
--- Comment #14 from steven at gcc dot gnu dot org 2006-05-05 18:42 --- Bud already voted to close this in comment #11 :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21130
[Bug objc/27240] [4.1/4.2 regression] ICE with invalid fields
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-05-05 19:48 --- Subject: Bug 27240 Author: reichelt Date: Fri May 5 19:48:26 2006 New Revision: 113559 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113559 Log: PR objc/27240 * objc-act.c (objc_is_public): Return early on invalid type. * objc.dg/member-1.m: New test. Added: trunk/gcc/testsuite/objc.dg/member-1.m Modified: trunk/gcc/objc/ChangeLog trunk/gcc/objc/objc-act.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27240
[Bug objc/27240] [4.1/4.2 regression] ICE with invalid fields
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-05-05 19:51 --- Subject: Bug 27240 Author: reichelt Date: Fri May 5 19:51:37 2006 New Revision: 113560 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113560 Log: PR objc/27240 * objc-act.c (objc_is_public): Return early on invalid type. * objc.dg/member-1.m: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/objc.dg/member-1.m Modified: branches/gcc-4_1-branch/gcc/objc/ChangeLog branches/gcc-4_1-branch/gcc/objc/objc-act.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27240
[Bug objc/27240] [4.1/4.2 regression] ICE with invalid fields
--- Comment #4 from reichelt at gcc dot gnu dot org 2006-05-05 19:54 --- Fixed on mainline and the 4.1 branch. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27240
[Bug target/27421] [4.0/4.1/4.2 regression] ICE with invalid array in struct
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-05-05 20:01 --- It's indeed the same issue as PR 24672. I knew there was a similar problem, but I couldn't find it. Testing a patch. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |reichelt at gcc dot gnu dot |dot org |org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27421
[Bug c/27420] ICE on invalid function definition
--- Comment #2 from patchapp at dberlin dot org 2006-05-05 20:03 --- Subject: Bug number PR c/27420 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00203.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27420
[Bug c++/27422] [4.0/4.1/4.2 regression] ICE with invalid function argument
--- Comment #3 from patchapp at dberlin dot org 2006-05-05 20:04 --- Subject: Bug number PR c++/27422 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00205.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27422
[Bug c++/27423] ICE on default argument for void parameter
--- Comment #4 from patchapp at dberlin dot org 2006-05-05 20:04 --- Subject: Bug number PR c++/27423 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00206.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27423
[Bug c++/27427] [4.0/4.1/4.2 regression] ICE with invalid template parameter
--- Comment #3 from patchapp at dberlin dot org 2006-05-05 20:05 --- Subject: Bug number PR c++/27427 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00207.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27427
[Bug c++/27430] ICE on array of voids as template parameter
--- Comment #3 from patchapp at dberlin dot org 2006-05-05 20:06 --- Subject: Bug number PR c++/27430 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00208.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27430
[Bug c/27450] New: [4.2 regression] gcc ICEs when compiling libavcodec from ffmpeg
Got this : cc -I../libvo -I../../libvo -fno-PIC -O4 -march=pentium-m -mtune=pentium-m -pipe -ffast-math -fomit-frame-pointer -D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DHAVE_AV_CONFIG_H -I.. -I/home/cartman/CVS/mplayer/libavutil -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_GNU_SOURCE-c -o dsputil.o dsputil.c dsputil.c: In function 'dct264_sad8x8_c': dsputil.c:3455: warning: passing argument 1 of 's-dsp.diff_pixels' from incompatible pointer type dsputil.c: In function 'h264_v_loop_filter_luma_c': dsputil.c:2794: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. make: *** [dsputil.o] Error 1 [EMAIL PROTECTED] libavcodec $ cc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-trunk/configure --prefix=/home/cartman/gcc4 --with-local-prefix=/home/cartman/gcc4 --enable-clocale=gnu --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-languages=c,c++ --enable-libgcc-math --with-arch=pentium-m --with-tune=pentium-m --disable-checking --disable-nls Thread model: posix gcc version 4.2.0 20060504 (experimental) -- Summary: [4.2 regression] gcc ICEs when compiling libavcodec from ffmpeg Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ismail at pardus dot org dot tr GCC build triplet: i686-gnu-linux GCC host triplet: i686-gnu-linux GCC target triplet: i686-gnu-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27450
[Bug middle-end/27450] [4.2 regression] gcc ICEs when compiling libavcodec from ffmpeg
--- Comment #1 from ismail at pardus dot org dot tr 2006-05-05 21:09 --- Created an attachment (id=11385) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11385action=view) Preprocessed source code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27450
[Bug middle-end/27450] [4.2 regression] gcc ICEs when compiling libavcodec from ffmpeg
--- Comment #2 from ismail at pardus dot org dot tr 2006-05-05 21:11 --- Created an attachment (id=11386) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11386action=view) dsputil.s -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27450
[Bug middle-end/27450] [4.2 regression] gcc ICEs when compiling libavcodec from ffmpeg
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-05-05 21:15 --- *** This bug has been marked as a duplicate of 27437 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27450
[Bug rtl-optimization/27437] [4.2 Regression] -O3 regression due to SEE
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-05-05 21:15 --- *** Bug 27450 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||ismail at pardus dot org dot ||tr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27437
[Bug target/8026] -fstack-check dumps when throw out of scope with
--- Comment #8 from sje at cup dot hp dot com 2006-05-05 21:19 --- Is it time to close this defect out? I tried to reproduce this on HP-UX with 3.4.5, 4.0.1, and 4.1 but they all worked. The 3.2 (and I think 3.3) branches are closed aren't they? -- sje at cup dot hp dot com changed: What|Removed |Added CC||sje at cup dot hp dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8026
[Bug libfortran/26985] [4.1 only] incorrect matmul result
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Keywords||patch Known to fail||4.1.1 Known to work||4.2.0 Summary|incorrect matmul result |[4.1 only] incorrect matmul ||result Target Milestone|--- |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26985
[Bug middle-end/14286] ICE with __builtin_va_start prototype
--- Comment #8 from sje at cup dot hp dot com 2006-05-05 21:36 --- Since this looks like an installation problem and not a real bug I am closing it out as invalid. -- sje at cup dot hp dot com changed: What|Removed |Added CC||sje at cup dot hp dot com Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14286
[Bug target/19770] gcc.c-torture/compile/20050113-1.c: ICE: in extract_insn, at recog.c:2083
--- Comment #4 from sje at cup dot hp dot com 2006-05-05 21:47 --- PR 21613 (same bug on a different platform) was closed with the comment that this got fixed when tree-ssa was merged in and that it would hard to fix in the 3.4 branch. I verified I can still see it on 3.4.5 and that it is not in 4.0.3 or 4.1. I will close this out as fixed in 4.0. Dave, let me know if you have any objections to this resolution. -- sje at cup dot hp dot com changed: What|Removed |Added CC||sje at cup dot hp dot com Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19770
[Bug fortran/25073] [missing testcase] CASEs overlap
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-05-05 21:47 --- I'll commit a testcase when I find some time this week-end... -- 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 Keywords|accepts-invalid | Last reconfirmed|2005-11-26 19:54:13 |2006-05-05 21:47:50 date|| Summary|CASEs overlap |[missing testcase] CASEs ||overlap http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25073
[Bug target/25286] [4.1/4.2 Regression] ext/pool_allocator/allocate_chunk.cc execution test fails
--- Comment #3 from sje at cup dot hp dot com 2006-05-05 22:11 --- I don't see this failure anymore so I think we can assume it was the same bug as PR 25168. Resolving as fixed. -- sje at cup dot hp dot com changed: What|Removed |Added CC||sje at cup dot hp dot com Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25286
[Bug rtl-optimization/27437] [4.2 Regression] -O3 regression due to SEE
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-05-05 22:18
---
Here is another testcase:
unsigned char clip_uint8(int a)
{
if (a(~255))
return (-a)31;
return a;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27437
[Bug middle-end/25586] FAIL: gfortran.dg/cray_pointers_2.f90 at -O2 and above
--- Comment #13 from sje at cup dot hp dot com 2006-05-05 22:21 --- Dave, it looks like this defect has been fixed. Is there any reason not to close the defect? -- sje at cup dot hp dot com changed: What|Removed |Added CC||sje at cup dot hp dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25586
[Bug rtl-optimization/27437] [4.2 Regression] -O3 regression due to SEE
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-05-05 22:22
---
My last case looks like HJL's 4 case. I wish x86 was not like this instead did
something different bug oh well
(insn:HI 6 8 7 2 (set (reg/v:SI 60 [ a ])
(mem/c/i:SI (reg/f:SI 16 argp) [2 a+0 S4 A32])) 34 {*movsi_1} (nil)
(expr_list:REG_EQUIV (mem/c/i:SI (reg/f:SI 16 argp) [2 a+0 S4 A32])
(nil)))
..
(insn:HI 18 17 19 3 (parallel [
(set (reg/v:SI 60 [ a ])
(ashiftrt:SI (reg/v:SI 60 [ a ])
(const_int 31 [0x1f])))
(clobber (reg:CC 17 flags))
]) 300 {*ashrsi3_1} (insn_list:REG_DEP_TRUE 17 (nil))
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))
(insn:HI 19 18 45 3 (parallel [
(set (reg:SI 58 [ D.1524 ])
(zero_extend:SI (subreg:QI (reg/v:SI 60 [ a ]) 0)))
(clobber (reg:CC 17 flags))
]) 77 {*zero_extendqisi2_movzbw_and} (insn_list:REG_DEP_TRUE 18 (nil))
(expr_list:REG_DEAD (reg/v:SI 60 [ a ])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil
..
( Cannot get here from insn 19)
(insn:HI 25 23 26 4 (parallel [
(set (reg:SI 58 [ D.1524 ])
(zero_extend:SI (subreg:QI (reg/v:SI 60 [ a ]) 0)))
(clobber (reg:CC 17 flags))
]) 77 {*zero_extendqisi2_movzbw_and} (nil)
(expr_list:REG_DEAD (reg/v:SI 60 [ a ])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27437
[Bug target/26226] FAIL: gcc.c-torture/execute/ieee/20010226-1.c execution
--- Comment #1 from sje at cup dot hp dot com 2006-05-05 22:32 --- This is an HP linker bug and it is in PHSS_33033 and possibly in some earlier linker patches too. There is a replacement for PHSS_33033 now. For HP-UX 11.00 the new patch is PHSS_33034 and for HP-UX 11.11 the new patch is PHSS_33035. -- sje at cup dot hp dot com changed: What|Removed |Added CC||sje at cup dot hp dot com Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26226
[Bug fortran/20248] gfortran: intrinsics and std=f95, inconsistency with other compilers
--- Comment #15 from anlauf at gmx dot de 2006-05-05 22:44 --- (In reply to comment #14) How does this look to you? Steve, this is perfect! Many thanks, -ha -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20248
[Bug middle-end/25586] FAIL: gfortran.dg/cray_pointers_2.f90 at -O2 and above
--- Comment #14 from danglin at gcc dot gnu dot org 2006-05-05 22:50 --- Fixed by patch 3.4 and leter. -- danglin at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25586
