[Bug fortran/50122] Same labels in nested scoping units rejected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50122 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||burnus at gcc dot gnu.org Resolution||INVALID --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2011-08-19 06:04:44 UTC --- While it is accepted by the Cray ftn compiler, http://j3-fortran.org/pipermail/j3/2011-August/004587.html is looks ambiguous which GOTO should be executed. Thus, not surprisingly, it is invalid as the standard seems to avoids resolving ambiguity by prioritizing the order. I think Malcolm is right by stating the following: http://j3-fortran.org/pipermail/j3/2011-August/004593.html The same statement label shall not be given to more than one statement in its scope. (F2008, 3.2.5 Statement labels) The scope of a label is an inclusive scope. The very text you quoted tells us that the inclusive scope includes both of those statements so you have not obeyed the rules. [...] We carefully worded this not to say scoping unit but scope precisely to get this effect! (For more F2008 quotes, see Malcolm's email and my initial J3 email (cf. bottom of comment 0).) As I concur with this analysis and as gfortran already rejects the code with duplicate statement label, I closed now the PR as INVALID.
[Bug libfortran/50105] [4.6/4.7 Regression] I/O with g6.5 - wrong number of ** shown
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50105
Tobias Burnus burnus at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |4.6.2
Summary|Possibly: I/O with g6.5 - |[4.6/4.7 Regression] I/O
|wrong number of ** shown |with g6.5 - wrong number of
||** shown
--- Comment #7 from Tobias Burnus burnus at gcc dot gnu.org 2011-08-19
06:15:56 UTC ---
I find the analysis of Malcolm (as usual) convincing, he thinks the correct
result is **.
Thus, I marked it again as regression - and removed the possibly from the
summary.
Malcolm wrote at http://j3-fortran.org/pipermail/j3/2011-August/004594.html
| The wording is quite tricky, you need to read it very carefully.
|
| It says (slight restructuring to make it clearer)
| On output,
|(a) if an exponent exceeds its specified or implied width using the ...
| G edit descriptor,
| or
|(b) the number of characters produced exceeds the field width,
|[you get stars]
|
| The bit that explicitly mentions G ***only applies to the exponent width
| being exceeded***.
|
| That is not the case here.
|
| What about the number of characters produced? Well, as Robert says, the
| F2.5 descriptor produces two characters (both stars) and the 4(' ')
| produces another 4, making a total of 6, within the width of G6.5.
|
| Perhaps this is merely bad wording, but it goes back a long way (F77).
And indeed not only gfortran 4.6.0, g95, NAG and PGI but also g77 produces
** .
(While with gfortran = 4.6.0, ifort, crayftn/open64/pathf95/sunf95 produce
**.)
(We might still see an interpretation request confirming Malcolm's
interpretation - or changing the standard such that ** is correct; only
the future will tell ...)
[Bug target/50123] cmpxchg generated for atomic and with zero/or with -1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50123
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org,
||amacleod at redhat dot com,
||jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2011-08-19
06:53:18 UTC ---
While we could do this on i?86/x86_64 now, it sounds better to do it in the
generic code (folding or expansion), but for that we need to wait for the
extended sync builtins that are currently brewing on cxx-mem-model branch
(because __sync_fetch_and_{and,or} are full barriers, while __sync_test_and_set
is not).
[Bug c++/50012] [4.5/4.6/4.7 Regression] C++ front end misses -Wsign-compare warnings when extraneous parentheses are present
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50012 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2011-08-19 07:29:07 UTC --- The problem is that we have just a single bit for the disabling of warning, we don't have a way to selectively disable just some warnings.
[Bug fortran/50121] Labels in a TYPE statement should be put in the derived type's scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50121 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-08-19 CC||burnus at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2011-08-19 07:33:46 UTC --- For completeness, the program in comment 0 works with g95, NAG, ifort, openf95/pathf95. (Though, in case of g95 seemingly by ignoring such labels in TYPE as adding another to the same type is not diagnosed. The other compilers do diagnose this.) Variant - failing in the same way with gfortran but working with the compiler mentioned above. 1 integer :: a 1 type t integer :: i end type t end
[Bug target/44995] define a macro for presence of -mregnames option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44995 Jan Kratochvil jan.kratochvil at redhat dot com changed: What|Removed |Added CC||jan.kratochvil at redhat ||dot com --- Comment #3 from Jan Kratochvil jan.kratochvil at redhat dot com 2011-08-19 08:05:07 UTC --- This seems to be now related to PR 32998 -grecord-gcc-switches although that works only with DWARF, -frecord-gcc-switches cannot differentiate between CUs.
[Bug middle-end/50113] [4.7 Regression] soft-float MIPS64 compiler is miscompiling ggc-page.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50113 rsand...@gcc.gnu.org rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||rsandifo at gcc dot gnu.org AssignedTo|unassigned at gcc dot |rsandifo at gcc dot gnu.org |gnu.org | --- Comment #6 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org 2011-08-19 08:13:34 UTC --- Related to PR50061 (although that's for hard rather than soft float).
[Bug target/49437] interrupt return pop sometimes corrupts sp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49437 --- Comment #3 from jye2 at gcc dot gnu.org 2011-08-19 08:28:15 UTC --- Author: jye2 Date: Fri Aug 19 08:28:08 2011 New Revision: 177891 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=177891 Log: PR target/49437 * config/arm/arm.c (arm_output_epilogue): Properly handle epilogue when stack was realigned in interrupt handler prologue. testsuite: PR target/49437 * gcc.target/arm/handler-align.c: New test. * lib/target-supports.exp (check_effective_target_arm_cortex_m): New Function. Added: trunk/gcc/testsuite/gcc.target/arm/handler-align.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/lib/target-supports.exp
[Bug target/49987] [4.7 Regression] gcc.c-torture/compile/pr34856.c fails on powerpc-darwin9 from r176228
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49987 --- Comment #8 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org 2011-08-19 08:31:43 UTC --- (In reply to comment #7) (In reply to comment #6) Created attachment 24987 [details] Revised patch Sorry, seems there are two copies of the logic. Please try this instead. yes, works for me off a stage3 bubble - not tested any other case yet tho. Thanks. Would you be able to run a full bootstrap and regression test with it? I'll submit the patch if that succeeds.
[Bug fortran/50109] [4.3/4.4/4.5/4.6 Regression] Formatted namelist read with multiple ! fails with: Cannot match namelist object name !
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50109 --- Comment #6 from Tobias Burnus burnus at gcc dot gnu.org 2011-08-19 09:14:59 UTC --- Author: burnus Date: Fri Aug 19 09:14:55 2011 New Revision: 177892 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=177892 Log: 2011-08-19 Tobias Burnus bur...@net-b.de PR fortran/50109 * io/list_read.c (eat_separator): Fix skipping over ! lines. 2011-08-19 Tobias Burnus bur...@net-b.de PR fortran/50109 * gfortran.dg/namelist_73.f90: New. Added: branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/namelist_73.f90 Modified: branches/gcc-4_6-branch/gcc/testsuite/ChangeLog branches/gcc-4_6-branch/libgfortran/ChangeLog branches/gcc-4_6-branch/libgfortran/io/list_read.c
[Bug fortran/50109] [4.3/4.4/4.5/4.6 Regression] Formatted namelist read with multiple ! fails with: Cannot match namelist object name !
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50109 --- Comment #7 from Tobias Burnus burnus at gcc dot gnu.org 2011-08-19 09:16:08 UTC --- Author: burnus Date: Fri Aug 19 09:16:03 2011 New Revision: 177893 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=177893 Log: 2011-08-19 Tobias Burnus bur...@net-b.de Backport from mainline 2011-08-18 Tobias Burnus bur...@net-b.de PR fortran/50109 * io/list_read.c (eat_separator): Fix skipping over ! lines. 2011-08-19 Tobias Burnus bur...@net-b.de Backport from mainline 2011-08-18 Tobias Burnus bur...@net-b.de PR fortran/50109 * gfortran.dg/namelist_73.f90: New. Added: branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/namelist_73.f90 Modified: branches/gcc-4_5-branch/gcc/testsuite/ChangeLog branches/gcc-4_5-branch/libgfortran/ChangeLog branches/gcc-4_5-branch/libgfortran/io/list_read.c
[Bug tree-optimization/50067] [4.7 Regression] Wrong code with -fpredictive-commoning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50067 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | --- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2011-08-19 09:14:20 UTC --- Mine.
[Bug c++/36993] g++ crashes with segfault upon wrong placement of case label
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36993 --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2011-08-19 09:17:02 UTC --- Jason, can you help me re-evaluating this? Is it an accepts-invalid now.. or not?
[Bug c++/50114] ICE on invalid code in pop_binding, at cp/name-lookup.c:382
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50114 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2011-08-19 09:18:00 UTC --- You know what I'm going to ask... ;)
[Bug target/49987] [4.7 Regression] gcc.c-torture/compile/pr34856.c fails on powerpc-darwin9 from r176228
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49987 --- Comment #9 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-08-19 09:40:18 UTC --- Would you be able to run a full bootstrap and regression test with it? I'll submit the patch if that succeeds. I have done a clean bootstrap of revision 177878 with the patch in comment #6. AFAICT the patch does not introduce any regression although I had to hunt some new failures due to revision 177691 (I'll submit a pr later today).
[Bug libfortran/50105] [4.6/4.7 Regression] I/O with g6.5 - wrong number of ** shown
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50105
--- Comment #8 from Tobias Burnus burnus at gcc dot gnu.org 2011-08-19
10:34:13 UTC ---
A simple (partial) revert of the patch of PR 47285
(http://gcc.gnu.org/ml/fortran/2011-01/msg00226.html) will lead to wrong
results as one does not honour the following.
write(*,'(G5.5E5)') -1.
will then print * instead of the correct * which is printed
currently. However, due to w-(e+2) = 5-(5+2) 0 [where the symbols are:
Gw.dEe], the whole field should be filled with asterisks, cf. below.
I think best is to do a full revert, replace the following hack in the patch
+ if (e 4)\
+e = 4;\
by a simply check for w-4 0 or w-(e+2) 0 and - if failing - fill it with
* and return. Only when succeeding, move to the FMT_F. In the latter padding
section, one can then always pad with ' '. I have not yet checked whether the
+ nb = nb = w ? 0 : nb;\
is then still required or not.
From the F2008 standard:
if an exponent exceeds its specified or implied width using the ... G edit
descriptor, [the field should be filled with *].
One has for Gw.d n = 4 and for Gw.d.Ee it is n = e+2. The requirement is
w-n 0. In that case, one needs to fill the whole width w (of Gw.d) with
asterisks.
If w-n 0, one has F(w-n).(dd),n(' ') with some dd depending on rounding
and magnitude of the value. In that case, only (w-n) is - if needed - filled
with asterisks.
(For the calculations, see 10.7.5.2.2 (below the first table); see also
10.7.2.1 in comment 1 with the interpretation in comment 7.)
[Bug tree-optimization/50067] [4.7 Regression] Wrong code with -fpredictive-commoning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50067
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
CC||spop at gcc dot gnu.org
--- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2011-08-19
11:16:41 UTC ---
I think the bug is that we have
#(Data Ref:
# bb: 3
# stmt: D.2736_10 = MEM[(int *)a + 16B];
# ref: MEM[(int *)a + 16B];
# base_object: a
# Access function 0: 16B
thus, an access function with a byte offset. I don't see how this couldn't
happen with the 4.5 code-base and the indirect-ref handling as well.
Thus, the code in dr_analyze_indices that pushes an access-function for
if (nest
(INDIRECT_REF_P (aref)
|| TREE_CODE (aref) == MEM_REF))
{
probably shouldn't do so if the base analysis
op = TREE_OPERAND (aref, 0);
access_fn = analyze_scalar_evolution (loop, op);
access_fn = instantiate_scev (before_loop, loop, access_fn);
isn't a POLYNOMIAL_CHREC. Because then we have no idea if the
steps / element sizes are compatible.
For example for
int a[256] = { 0, 0, 0, 0, 7, 9, 0, 0, };
int main()
{
int i;
for (i = 0; i 256; ++i)
{
a[i] = (*((char(*)[8])a[4]))[i];
}
}
we create
Creating dr for MEM[(char[8] *)a + 16B][i_12]
analyze_innermost: success.
base_address: a
offset from base address: 0
constant offset from base address: 16
step: 1
aligned to: 128
base_object: MEM[(char[8] *)a]
Creating dr for a[i_12]
analyze_innermost: success.
base_address: a
offset from base address: 0
constant offset from base address: 0
step: 4
aligned to: 128
base_object: a
(compute_affine_dependence
(stmt_a =
D.2727_4 = MEM[(char[8] *)a + 16B][i_12];
)
(stmt_b =
a[i_12] = D.2728_5;
)
)
(Data Dep:
#(Data Ref:
# bb: 3
# stmt: D.2727_4 = MEM[(char[8] *)a + 16B][i_12];
# ref: MEM[(char[8] *)a + 16B][i_12];
# base_object: MEM[(char[8] *)a];
# Access function 0: {0, +, 1}_1
# Access function 1: 16B
#)
#(Data Ref:
# bb: 3
# stmt: a[i_12] = D.2728_5;
# ref: a[i_12];
# base_object: a
# Access function 0: {0, +, 1}_1
#)
(don't know)
with a mismatched number of access functions.
On the 4.5 branch we seem to do the same and we seem to rely on the
mismatch in the number of access functions to say don't know for
dependence analysis. Testcase:
extern void abort (void);
int a[6] = { 0, 0, 0, 0, 7, 0 };
int
main ()
{
int i;
int (*p)[1] = a[4];
for (i = 0; i 4; ++i)
{
a[i + 1] = a[i + 2] i;
(*p)[i] = ~1;
}
if (a[4] != 0)
abort ();
return 0;
}
#(Data Ref:
# stmt: D.2727_9 = (*p_3)[i_19];
# ref: (*p_3)[i_19];
# base_object: (*(int[1] *) a)[0];
# Access function 0: {0, +, 1}_1
# Access function 1: 16B
so the new issue seems to be that with invariant DRs now allowed
we have a spurious match in access functions, because with a
non-indirect ref base we do not add a access function for the base
(which would be simply 0B).
Of course then still
(Data Dep:
#(Data Ref:
# bb: 3
# stmt: D.2727_4 = MEM[(char[8] *)a + 16B][i_12];
# ref: MEM[(char[8] *)a + 16B][i_12];
# base_object: a
# Access function 0: {0, +, 1}_1
# Access function 1: 16B
#)
#(Data Ref:
# bb: 3
# stmt: a[i_12] = D.2728_5;
# ref: a[i_12];
# base_object: a
# Access function 0: {0, +, 1}_1
# Access function 1: 0
#)
(no dependence)
because the code assumes that access functions affect independent
index spaces, if you look at
int a[256] = { 0, 0, 0, 0, 7, 9, 0, 0, };
int main()
{
int i;
for (i = 0; i 256; ++i)
{
a[i] = (*((char(*)[8])a[4]))[i];
}
}
so it seems that rather than adding a separate access function for
the base pointer object (which could be dependent on i as well!)
we shouldn't do that at all.
Sebastian - do you remember anything about this code?
I'd simply do
Index: tree-data-ref.c
===
--- tree-data-ref.c (revision 177891)
+++ tree-data-ref.c (working copy)
@@ -862,34 +862,6 @@ dr_analyze_indices (struct data_referenc
aref = TREE_OPERAND (aref, 0);
}
- if (nest
- (INDIRECT_REF_P (aref)
- || TREE_CODE (aref) == MEM_REF))
-{
- op = TREE_OPERAND (aref, 0);
- access_fn = analyze_scalar_evolution (loop, op);
- access_fn = instantiate_scev (before_loop, loop, access_fn);
- base = initial_condition (access_fn);
- split_constant_offset (base, base, off);
- if (TREE_CODE (aref) == MEM_REF)
- off = size_binop (PLUS_EXPR, off,
- fold_convert (ssizetype, TREE_OPERAND (aref, 1)));
- access_fn = chrec_replace_initial_condition (access_fn,
- fold_convert (TREE_TYPE (base), off));
-
- TREE_OPERAND (aref, 0) = base;
- VEC_safe_push
[Bug target/44995] define a macro for presence of -mregnames option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44995 --- Comment #4 from Frank Ch. Eigler fche at redhat dot com 2011-08-19 11:24:19 UTC --- We have worked around this powerpc oddity in systemtap's recent sdt.h versions by using both %0 and %I0 together to get a special markup for literals vs. register names.
[Bug tree-optimization/50067] [4.7 Regression] Wrong code with -fpredictive-commoning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50067 --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2011-08-19 11:36:42 UTC --- Can't we just standardize on some particular element size (say derived from DR_BASE_ADDRESS's type or even record it in the data_reference structure), use it if it can be expressed in those units and give up otherwise (both for ARRAY_REF and for MEM_REF offsets)?
[Bug tree-optimization/50067] [4.7 Regression] Wrong code with -fpredictive-commoning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50067
--- Comment #8 from Richard Guenther rguenth at gcc dot gnu.org 2011-08-19
11:51:07 UTC ---
We seem to be safe in more cases also because of weird stripping of
MEM_REFs in dr_analyze_indices.
if (TREE_CODE (ref) == MEM_REF
TREE_CODE (TREE_OPERAND (ref, 0)) == ADDR_EXPR
integer_zerop (TREE_OPERAND (ref, 1)))
ref = TREE_OPERAND (TREE_OPERAND (ref, 0), 0);
if you move that after stripping zero-offset ARRAY_REFs (to also
strip the mem-ref to the base object for (*a)[i]) then we miscompile
the following testcase because we vectorize it
extern int memcmp(const void *, const void *, __SIZE_TYPE__);
extern void abort (void);
short a[32] = { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17,
18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31 };
short b[32] = { 4, 0, 5, 0, 6, 0, 7, 0, 8, 0, };
int main()
{
int i;
for (i = 0; i 32; ++i)
{
a[i] = (*((char(*)[32])a[0]))[i+8];
}
if (memcmp (a, b, sizeof (a)) != 0)
abort ();
return 0;
}
when we leave two mem-refs around with
extern int memcmp(const void *, const void *, __SIZE_TYPE__);
extern void abort (void);
short a[32] = { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17,
18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31 };
short b[32] = { 4, 0, 5, 0, 6, 0, 7, 0, 8, 0, };
int main()
{
int i;
for (i = 0; i 32; ++i)
{
(*((unsigned short(*)[32])a[0]))[i] = (*((char(*)[32])a[0]))[i+8];
}
if (memcmp (a, b, sizeof (a)) != 0)
abort ();
return 0;
}
then the base-object comparison fails.
I wonder if the C access-as character lvalue covers doing so through
arbitrary dimensioned char arrays ...
I'll be incrementally trying to fix some oddities in dr_analyze_indices.
[Bug fortran/50109] [4.3/4.4/4.5/4.6 Regression] Formatted namelist read with multiple ! fails with: Cannot match namelist object name !
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50109 --- Comment #8 from Tobias Burnus burnus at gcc dot gnu.org 2011-08-19 11:55:19 UTC --- Author: burnus Date: Fri Aug 19 11:55:16 2011 New Revision: 177895 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=177895 Log: 2011-08-19 Tobias Burnus bur...@net-b.de Backport from mainline 2011-08-18 Tobias Burnus bur...@net-b.de PR fortran/50109 * io/list_read.c (eat_separator): Fix skipping over ! lines. 2011-08-19 Tobias Burnus bur...@net-b.de Backport from mainline 2011-08-18 Tobias Burnus bur...@net-b.de PR fortran/50109 * gfortran.dg/namelist_73.f90: New. Added: branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/namelist_73.f90 Modified: branches/gcc-4_4-branch/gcc/testsuite/ChangeLog branches/gcc-4_4-branch/libgfortran/ChangeLog branches/gcc-4_4-branch/libgfortran/io/list_read.c
[Bug tree-optimization/50067] [4.7 Regression] Wrong code with -fpredictive-commoning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50067 --- Comment #9 from Richard Guenther rguenth at gcc dot gnu.org 2011-08-19 12:00:11 UTC --- I think the element sizes of the access functions need to be reflected in the base object, which we require to be operand_equal_p to any other base to which we compare our access functions. I'm not yet 100% convinced that is enough though (if you view two same-shaped two-dimensional slices from a 3d array, for example, (int (*)[16][16])a[i][j][k] and (int (*)[16][16])a[l][m][n] and index them with [p][q] it should be possible to choose i,j,k,l,m,n so that data-dependence analysis thinks they do not overlap while they do - well, hopefully not ;)). I'm checking what regressions it will cause to remove if (TREE_CODE (ref) == MEM_REF TREE_CODE (TREE_OPERAND (ref, 0)) == ADDR_EXPR integer_zerop (TREE_OPERAND (ref, 1))) ref = TREE_OPERAND (TREE_OPERAND (ref, 0), 0); which should fix this part for the particular case of an outermost-only mem-ref (that's the case where it doesn't help too much anyway, and moving it to a more useful place creates even more issues, see comment #8).
[Bug c++/36993] g++ crashes with segfault upon wrong placement of case label
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36993 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #6 from Jason Merrill jason at gcc dot gnu.org 2011-08-19 12:58:47 UTC --- 4.7 will say wa.C:5:9: error: case label ‘1’ not within a switch statement
[Bug tree-optimization/50124] New: gfortran.dg/graphite/interchange-1.f XPASSes everywhere
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50124 Bug #: 50124 Summary: gfortran.dg/graphite/interchange-1.f XPASSes everywhere Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: r...@gcc.gnu.org CC: s...@gcc.gnu.org Host: *-*-solaris2.*, mips-sgi-irix6.5 Target: *-*-solaris2.*, mips-sgi-irix6.5 Build: *-*-solaris2.*, mips-sgi-irix6.5 Since 20110805, the gfortran.dg/graphite/interchange-1.f test seems to XPASS everywhere. Is this expected and can the xfail be removed to reduce testsuite noise? Rainer
[Bug fortran/49792] OpenMP workshare: Wrong result with array assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49792 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2011-08-19 13:25:26 UTC --- Author: jakub Date: Fri Aug 19 13:25:22 2011 New Revision: 177898 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=177898 Log: PR fortran/49792 * trans-expr.c (gfc_trans_assignment_1): Set OMPWS_SCALARIZER_WS bit in ompws_flags only if loop.temp_ss is NULL, and clear it if lhs needs reallocation. * trans-openmp.c (gfc_trans_omp_workshare): Don't return early if code is NULL, emit a barrier if workshare emitted no code at all and NOWAIT clause isn't present. * testsuite/libgomp.fortran/pr49792-1.f90: New test. * testsuite/libgomp.fortran/pr49792-2.f90: New test. Added: trunk/libgomp/testsuite/libgomp.fortran/pr49792-1.f90 trunk/libgomp/testsuite/libgomp.fortran/pr49792-2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-openmp.c trunk/libgomp/ChangeLog
[Bug fortran/49792] OpenMP workshare: Wrong result with array assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49792 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2011-08-19 13:26:54 UTC --- Author: jakub Date: Fri Aug 19 13:26:50 2011 New Revision: 177900 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=177900 Log: PR fortran/49792 * trans-expr.c (gfc_trans_assignment_1): Set OMPWS_SCALARIZER_WS bit in ompws_flags only if loop.temp_ss is NULL, and clear it if lhs needs reallocation. * trans-openmp.c (gfc_trans_omp_workshare): Don't return early if code is NULL, emit a barrier if workshare emitted no code at all and NOWAIT clause isn't present. * testsuite/libgomp.fortran/pr49792-1.f90: New test. * testsuite/libgomp.fortran/pr49792-2.f90: New test. Added: branches/gcc-4_6-branch/libgomp/testsuite/libgomp.fortran/pr49792-1.f90 branches/gcc-4_6-branch/libgomp/testsuite/libgomp.fortran/pr49792-2.f90 Modified: branches/gcc-4_6-branch/gcc/fortran/ChangeLog branches/gcc-4_6-branch/gcc/fortran/trans-expr.c branches/gcc-4_6-branch/gcc/fortran/trans-openmp.c branches/gcc-4_6-branch/libgomp/ChangeLog
[Bug middle-end/50125] New: gcc.dg/uninit-B.c and gcc.dg/uninit-pr19430.c XPASS everywhere
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50125 Bug #: 50125 Summary: gcc.dg/uninit-B.c and gcc.dg/uninit-pr19430.c XPASS everywhere Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: r...@gcc.gnu.org Since 20110812, gcc.dg/uninit-B.c and gcc.dg/uninit-pr19430.c XPASS everywhere. If this is intentional, the xfails should be removed to reduce testsuite noise. Rainer
[Bug fortran/50109] [4.3/4.4/4.5/4.6/4.7 Regression] Formatted namelist read with multiple ! fails with: Cannot match namelist object name !
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50109 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Summary|[4.3/4.4/4.5/4.6|[4.3/4.4/4.5/4.6/4.7 |Regression] Formatted |Regression] Formatted |namelist read with multiple |namelist read with multiple |! fails with: Cannot |! fails with: Cannot |match namelist object name |match namelist object name |! |! --- Comment #9 from Tobias Burnus burnus at gcc dot gnu.org 2011-08-19 13:33:20 UTC --- FIXED on the 4.4, 4.5 and 4.6 branches and on the trunk (4.7). I did not back port the fix to the no longer maintained 4.3 branch. Thanks for that bugreport! At least for the Linux version, there should be very soon a new build available at http://gcc.gnu.org/wiki/GFortranBinaries ; I think the Darwin builds are less regularly updated. Otherwise, you either need to build it yourself or wait for an updated version (linked on that page or of your distribution).
[Bug c++/50126] New: g++ does not recognize a friend declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50126
Bug #: 50126
Summary: g++ does not recognize a friend declaration
Classification: Unclassified
Product: gcc
Version: 4.4.5
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pisetta.gia...@alice.it
Created attachment 25054
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25054
intermediate file
compiling the code of test.cpp:
---
templateclass A,class B class X {
public:
templateclass C XC,B operator[]( const C );
};
templateclass A,class B,class C class Y : public XC,B {
friend XC,B XA,B::template operator[]C( const C );
private:
Y( XA,B object , const C index ) : XC,B() {};
};
templateclass A,class B templateclass C XC,B XA,B::operator[]( const
C index ) {
return *( new YA,B,C( *this , index ) );
}
void test() {
Xint,void x;
Xint,void y = x[2];
}
---
with the command line:
g++ -c test.cpp -o test.cpp
report:
./test.cpp: In instantiation of ‘Yint, void, int’:
./test.cpp:14: instantiated from ‘XC, B XA, B::operator[](const C)
with [C = int, A = int, B = void]’
./test.cpp:19: instantiated from here
./test.cpp:8: error: ‘operator[]’ not defined
./test.cpp: In member function ‘XC, B XA, B::operator[](const C) [with
C = int, A = int, B = void]’:
./test.cpp:19: instantiated from here
./test.cpp:10: error: ‘YA, B, C::Y(XA, B, const C) [with A = int, B =
void, C = int]’ is private
./test.cpp:14: error: within this context
I asked on the internet and it seems that it is a valid friend declaration.
Compiling the same code with 'clang' does not report any error.
The only workaround is to use a template friend declaration like:
templateclass A,class B,class C class Y : public XC,B {
templateclass CC friend XCC,B XA,B::operator[]( const CC );
but it declares every generated operator[] as friend of class Y, so it is
dangerous.
g++ version:
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.5-8'
--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.4 --enable-shared --enable-multiarch
--enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.4 --libdir=/usr/lib --enable-nls
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc
--enable-targets=all --with-arch-32=i586 --with-tune=generic
--enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu
--target=i486-linux-gnu
Thread model: posix
gcc version 4.4.5 (Debian 4.4.5-8)
[Bug fortran/49792] OpenMP workshare: Wrong result with array assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49792 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011-08-19 CC||jakub at gcc dot gnu.org AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2011-08-19 13:35:46 UTC --- Fixed for 4.6+ so far.
[Bug tree-optimization/50067] [4.7 Regression] Wrong code with -fpredictive-commoning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50067
--- Comment #10 from Richard Guenther rguenth at gcc dot gnu.org 2011-08-19
13:36:49 UTC ---
Testcase showing that stripping the offset for the indirect base is bogus:
extern int memcmp(const void *, const void *, __SIZE_TYPE__);
extern void abort (void);
short a[33] = { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17,
18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31 };
short b[33] = { 0, };
int main()
{
int i;
for (i = 0; i 64; ++i)
{
(*((char(*)[])a[1]))[i] = (*((char(*)[])a[0]))[i+1];
}
if (memcmp (a, b, sizeof (a)) != 0)
abort ();
return 0;
}
is vectorized because:
Creating dr for MEM[(char[unknown] *)a][i_5]
analyze_innermost: success.
base_address: a
offset from base address: 0
constant offset from base address: 1
step: 1
aligned to: 128
base_object: MEM[(char[unknown] *)a]
Creating dr for MEM[(char[unknown] *)a + 2B][i_15]
analyze_innermost: success.
base_address: a
offset from base address: 0
constant offset from base address: 2
step: 1
aligned to: 128
base_object: MEM[(char[unknown] *)a]
(compute_affine_dependence
(stmt_a =
D.2739_6 = MEM[(char[unknown] *)a][i_5];
)
(stmt_b =
MEM[(char[unknown] *)a + 2B][i_15] = D.2739_6;
)
(subscript_dependence_tester
(analyze_overlapping_iterations
(chrec_a = {1, +, 1}_1)
(chrec_b = {0, +, 1}_1)
(analyze_siv_subscript
(analyze_subscript_affine_affine
(overlaps_a = [0 + 1 * x_1]
)
(overlaps_b = [1 + 1 * x_1]
)
)
)
(overlap_iterations_a = [0 + 1 * x_1]
)
(overlap_iterations_b = [1 + 1 * x_1]
)
)
(analyze_overlapping_iterations
(chrec_a = 0B)
(chrec_b = 2B)
(analyze_ziv_subscript
)
(overlap_iterations_a = no dependence
)
(overlap_iterations_b = no dependence
)
)
(dependence classified: scev_known)
)
)
well - that access_fn created for the indirect base is thought to be
independent on any of the other access_fns:
(Data Dep:
#(Data Ref:
# bb: 3
# stmt: D.2739_20 = MEM[(char[unknown] *)a][i_19];
# ref: MEM[(char[unknown] *)a][i_19];
# base_object: MEM[(char[unknown] *)a];
# Access function 0: {1, +, 1}_2
# Access function 1: 0B
#)
#(Data Ref:
# bb: 3
# stmt: MEM[(char[unknown] *)a + 2B][i_10] = D.2739_20;
# ref: MEM[(char[unknown] *)a + 2B][i_10];
# base_object: MEM[(char[unknown] *)a];
# Access function 0: {0, +, 1}_2
# Access function 1: 2B
#)
(no dependence)
that's clearly bogus.
[Bug fortran/50109] [4.3/4.4/4.5/4.6/4.7 Regression] Formatted namelist read with multiple ! fails with: Cannot match namelist object name !
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50109 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #10 from Tobias Burnus burnus at gcc dot gnu.org 2011-08-19 13:45:38 UTC --- Really close as FIXED.
[Bug rtl-optimization/50101] GCC 4.5 and 4.6 generate suboptimal code on ppc for countdown loops when the CTR register cannot be used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50101 --- Comment #8 from Michael Meissner meissner at linux dot vnet.ibm.com 2011-08-19 14:05:51 UTC --- On Thu, Aug 18, 2011 at 08:58:28AM +, rguenth at gcc dot gnu.org wrote: Did you try pessimizing the non-ctr reg alternatives (and the memory alternative even more)? Like adding ! to the non-ctr alternatives and ? to the memory one? Not sure if those markers are looked at by IRA though. Yes, I should have mentioned that I tried various combinations of ?, !, and * and the combinations I tried aborted. I've certainly suspected that IRA now longer looks at !, ?, and * like the previous register allocator did previously. It may be that it is special due to being a JUMP_INSN.
[Bug gcov-profile/50127] New: [4.7 regression] g++.dg/tree-prof/partition2.C FAILs on several targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50127 Bug #: 50127 Summary: [4.7 regression] g++.dg/tree-prof/partition2.C FAILs on several targets Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Keywords: assemble-failure Severity: normal Priority: P3 Component: gcov-profile AssignedTo: unassig...@gcc.gnu.org ReportedBy: r...@gcc.gnu.org Host: *-*-solaris2.*, i386-apple-darwin, x86_64-unknown-linux-gnu Target: *-*-solaris2.*, i386-apple-darwin, x86_64-unknown-linux-gnu Build: *-*-solaris2.*, i386-apple-darwin, x86_64-unknown-linux-gnu Between 20110722 and 20110729, g++.dg/tree-prof/partition2.C started to FAIL on several targets: FAIL: g++.dg/tree-prof/partition2.C compilation, -Os -fprofile-use UNRESOLVED: g++.dg/tree-prof/partition2.C execution,-Os -fprofile-use On Solaris, the error happens with both Sun as ... output is: Assembler: partition2.C /var/tmp//ccdbaqzf.s, line 79 : Illegal subtraction - symbols from different sections: .L5, .LFB0 ... and gas: output is: /var/tmp//ccXAayTS.s: Assembler messages: /var/tmp//ccXAayTS.s:95: Error: invalid operands (.text.unlikely and .text.startup sections) for `-' Likewise on Linux/amd64. This is a regression from 4.5 and 4.6. At the same time (and only on Solaris, it seems), another tree-prof test started to fail: FAIL: gcc.dg/tree-prof/bb-reorg.c execution,-fprofile-use -D_PROFILE_USE But only for 64-bit Solaris/x86. I haven't investigated in more detail what's wrong here.
[Bug gcov-profile/50127] [4.7 regression] g++.dg/tree-prof/partition2.C FAILs on several targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50127 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-08-19 14:22:34 UTC --- See pr50035 marked as a duplicate of bug 49972.
[Bug tree-optimization/50067] [4.7 Regression] Wrong code with -fpredictive-commoning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50067 --- Comment #11 from Richard Guenther rguenth at gcc dot gnu.org 2011-08-19 14:23:51 UTC --- That is exposed by my 2nd posted patch as well, for gcc.c-torture/execute/pr33870-1.c. Testing a fix.
[Bug tree-optimization/50067] [4.7 Regression] Wrong code with -fpredictive-commoning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50067 --- Comment #12 from Richard Guenther rguenth at gcc dot gnu.org 2011-08-19 14:26:19 UTC --- Author: rguenth Date: Fri Aug 19 14:26:13 2011 New Revision: 177903 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=177903 Log: 2011-08-19 Richard Guenther rguent...@suse.de PR tree-optimization/50067 * tree-data-ref.c (dr_analyze_indices): Simplify, strip MEM_REF offset only if we accounted for it. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-data-ref.c
[Bug gcov-profile/50127] [4.7 regression] g++.dg/tree-prof/partition2.C FAILs on several targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50127 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Depends on||49972 --- Comment #2 from Rainer Orth ro at gcc dot gnu.org 2011-08-19 14:29:26 UTC --- The partition2.C part is a duplicate, the bb-reorg.c might be as well.
[Bug target/48338] [4.7 Regression] Glibc miscompiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48338 --- Comment #8 from H.J. Lu hjl.tools at gmail dot com 2011-08-19 14:34:33 UTC --- This may be a glibc bug: http://sourceware.org/ml/libc-alpha/2011-08/msg00063.html
[Bug c++/36993] g++ crashes with segfault upon wrong placement of case label
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36993 --- Comment #7 from Paolo Carlini paolo.carlini at oracle dot com 2011-08-19 14:39:12 UTC --- Oops, I completely missed the fix going in. Thanks anyway!
[Bug rtl-optimization/50101] GCC 4.5 and 4.6 generate suboptimal code on ppc for countdown loops when the CTR register cannot be used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50101 --- Comment #9 from Jeffrey A. Law law at redhat dot com 2011-08-19 15:35:36 UTC --- -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/19/11 08:05, meissner at linux dot vnet.ibm.com wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50101 --- Comment #8 from Michael Meissner meissner at linux dot vnet.ibm.com 2011-08-19 14:05:51 UTC --- On Thu, Aug 18, 2011 at 08:58:28AM +, rguenth at gcc dot gnu.org wrote: Did you try pessimizing the non-ctr reg alternatives (and the memory alternative even more)? Like adding ! to the non-ctr alternatives and ? to the memory one? Not sure if those markers are looked at by IRA though. Yes, I should have mentioned that I tried various combinations of ?, !, and * and the combinations I tried aborted. I've certainly suspected that IRA now longer looks at !, ?, and * like the previous register allocator did previously. It may be that it is special due to being a JUMP_INSN. I wonder if we could record which allocnos correspond to outputs of JUMP_INSNS, then in the allocno sorting code, move all of them to the front of the list. In effect, this makes those allocnos have higher priority for getting a hard reg than everything else. Thoughts? Jeff -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOToKzAAoJEBRtltQi2kC761UIAK4E0qfQ174Zakhd3JpDuLZ5 teyBgLTnoNMmO1pIdY/SgDP39PvtG9zwFoUwUDljDfZNbwVEHr2EmFgdu6RzmEAM H6NvI40PPKvN9YIY4hkT007OWKatXU2IrXnHij0ZoEIktobLbC38vz6JHTfNDJkW Bl9MKBeVfvMma7yzEZ2tgIXwy16SNuebHJuU6718uooMMwZ2agDWad9CsPvVGRtj yzuvUQH3qg/ZdCfCfHKF+0hKzLe/1S4XNBt8X8Ezj582CR8irDzOngGQkagDvpTz DXwGKDKBUjMAO3VYEw6GYWbfyxsnv1VFaXezNj/9/QpVKswvRi5vtHhii3LYzlY= =vmEo -END PGP SIGNATURE-
[Bug bootstrap/50128] New: [4.7 Regression] bootstrap failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50128 Bug #: 50128 Summary: [4.7 Regression] bootstrap failure Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com CC: a...@gcc.gnu.org On Linux/x86, revision 177908 gave: trunk/libgcc/../include -I../../../src-trunk/libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS -DUSE_TLS -o bid32_to_bid64.o -MT bid32_to_bid64.o -MD -MP -MF bid32_to_bid64.dep -c ../../../src-trunk/libgcc/config/libbid/bid32_to_bid64.c res_12 = D.7178_38 w* 10; ../../../src-trunk/libgcc/config/libbid/bid32_to_bid64.c: In function '__bid32_to_bid64': ../../../src-trunk/libgcc/config/libbid/bid32_to_bid64.c:29:1: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[6]: *** [bid32_to_bid64.o] Error 1 make[6]: *** Waiting for unfinished jobs PD_359 = digit_22 w* 109951163; ../../../src-trunk/libgcc/config/libbid/bid64_div.c: In function '__bid64_div': ../../../src-trunk/libgcc/config/libbid/bid64_div.c:80:1: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[6]: *** [bid64_div.o] Error 1 PD_927 = digit_3 w* 109951163; PD_1008 = digit_4 w* 109951163; ../../../src-trunk/libgcc/config/libbid/bid128_div.c: In function '__bid128_div': ../../../src-trunk/libgcc/config/libbid/bid128_div.c:36:1: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[6]: *** [bid128_div.o] Error 1 Revision 177900 is OK.
[Bug rtl-optimization/50107] [IRA, i386] allocates registers in very non-optimal way
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50107
--- Comment #13 from H.J. Lu hjl.tools at gmail dot com 2011-08-19 16:05:58
UTC ---
We start with
(insn 11 4 16 2 (set (reg:TI 65)
(mult:TI (zero_extend:TI (reg/v:DI 64 [ b ]))
(zero_extend:TI (reg/v:DI 63 [ a ] uti-2.i:3 339
{bmi2_umulditi3_1}
(expr_list:REG_DEAD (reg/v:DI 64 [ b ])
(expr_list:REG_DEAD (reg/v:DI 63 [ a ])
(nil
(insn 16 11 19 2 (set (reg/i:TI 0 ax)
(reg:TI 65)) uti-2.i:4 60 {*movti_internal_rex64}
(expr_list:REG_DEAD (reg:TI 65)
(nil)))
and IRA generates:
(insn 24 4 11 2 (set (reg:DI 1 dx)
(reg/v:DI 4 si [orig:64 b ] [64])) uti-2.i:3 62 {*movdi_internal_rex64}
(nil))
(insn 11 24 16 2 (set (reg:TI 4 si [65])
(mult:TI (zero_extend:TI (reg:DI 1 dx))
(zero_extend:TI (reg/v:DI 5 di [orig:63 a ] [63] uti-2.i:3 339
{bmi2_umulditi3_1}
(nil))
(insn 16 11 19 2 (set (reg/i:TI 0 ax)
(reg:TI 4 si [65])) uti-2.i:4 60 {*movti_internal_rex64}
(nil))
(insn 19 16 22 2 (use (reg/i:TI 0 ax)) uti-2.i:4 -1
(nil))
[Bug rtl-optimization/50107] [IRA, i386] allocates registers in very non-optimal way
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50107
--- Comment #14 from Vladimir Makarov vmakarov at redhat dot com 2011-08-19
16:12:48 UTC ---
(In reply to comment #11)
(In reply to comment #10)
movq%rdi, %rdx
mulx%rsi, %rax, %rsi
movq%rsi, %rdx
ret
.cfi_endproc
.LFE0:
.sizetest_mul_64, .-test_mul_64
.identGCC: (GNU) 4.7.0 20110818 (experimental)
.section.note.GNU-stack,,@progbits
[hjl@gnu-6 pr50107]$
I would expect
movq%rdi, %rdx
mulx%rsi, %rax, %rdx
ret
I think it i a reload problem. IRA assigns dx to pseudo 71 (an insn output)
but reload then spills it.
uti-2.i.188r.asmcons has
(insn 11 4 24 2 (parallel [
(set (reg:DI 72)
(mult:DI (reg/v:DI 64 [ b ])
(reg/v:DI 63 [ a ])))
(set (reg:DI 73 [+8 ])
(truncate:DI (ashiftrt:TI (mult:TI (zero_extend:TI (reg/v:DI
64
[ b ]))
(zero_extend:TI (reg/v:DI 63 [ a ])))
(const_int 64 [0x40]
]) uti-2.i:3 339 {bmi2_mulxditi3_internal}
(expr_list:REG_DEAD (reg/v:DI 64 [ b ])
(expr_list:REG_DEAD (reg/v:DI 63 [ a ])
(nil
uti-2.i.191r.ira generates:
(insn 11 28 25 2 (parallel [
(set (reg:DI 0 ax [72])
(mult:DI (reg/v:DI 4 si [orig:64 b ] [64])
(reg:DI 1 dx)))
(set (reg:DI 4 si [orig:73+8 ] [73])
(truncate:DI (ashiftrt:TI (mult:TI (zero_extend:TI (reg/v:DI 4
s
i [orig:64 b ] [64]))
(zero_extend:TI (reg:DI 1 dx)))
(const_int 64 [0x40]
]) uti-2.i:3 339 {bmi2_mulxditi3_internal}
(nil))
Why does IRA/reload choose SI for pseudo 73?
IRA assigns dx to pseudo 73. Than reload pass needs dx for pseudo 63 and
reload spills 73 and assigns si to 73 again. Reload pass spills pseudo 73
because it believes that pseudos living through insn or dead or set (pseudo 73
is set) in the insn conflict with necessary reload.
Of course it is really not necessary to spill pseudo 73, but to teach reload
pass to that is a big, error-prune project. I'd not recommend to start it.
I myself am not interesting to work on the reload pass. Instead I prefer to
work on LRA (local RA) which is a reload pass replacement.
[Bug bootstrap/50128] [4.7 Regression] bootstrap failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50128 --- Comment #1 from Andrew Stubbs ams at gcc dot gnu.org 2011-08-19 16:24:09 UTC --- I believe this is fixed in 177910, if not before.
[Bug tree-optimization/48739] [4.5/4.6/4.7 Regression] ICE in check_loop_closed_ssa_use() with -ftree-parallelize-loops=2 -fno-tree-dominator-opts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48739
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Target Milestone|--- |4.5.4
Summary|ICE in |[4.5/4.6/4.7 Regression]
|check_loop_closed_ssa_use() |ICE in
|with|check_loop_closed_ssa_use()
|-ftree-parallelize-loops=2 |with
|-fno-tree-dominator-opts |-ftree-parallelize-loops=2
||-fno-tree-dominator-opts
--- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2011-08-19
16:38:45 UTC ---
Simplified testcase:
/* PR tree-optimization/48739 */
/* { dg-do compile } */
/* { dg-options -O1 -ftree-parallelize-loops=2 -fno-tree-dominator-opts } */
extern int g;
extern void bar (void);
int
foo (int x)
{
int a, b, *c = (int *) 0;
for (a = 0; a 10; ++a)
{
bar ();
for (b = 0; b 5; ++b)
{
x = 0;
c = x;
g = 1;
}
}
*c = x;
for (x = 0; x != 10; x++)
;
return g;
}
Started with http://gcc.gnu.org/viewcvs?root=gccview=revrev=149206
(before that the empty loop would be just removed).
The bug seems to be that parloops pass requests TODO_rebuild_alias which
changes x from TREE_ADDRESSABLE to a gimple var, but we are in loop closed SSA
form at that point and nothing ensures that the optimized variable is put into
loop closed SSA form.
[Bug tree-optimization/48739] [4.5/4.6/4.7 Regression] ICE in check_loop_closed_ssa_use() with -ftree-parallelize-loops=2 -fno-tree-dominator-opts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48739 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-08-19 Ever Confirmed|0 |1 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2011-08-19 16:43:03 UTC --- If the loop is non-empty, such as containing v[x] = x; and extern int v[10];, then it started failing with http://gcc.gnu.org/viewcvs?root=gccview=revrev=145494
[Bug bootstrap/50128] [4.7 Regression] bootstrap failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50128 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #2 from H.J. Lu hjl.tools at gmail dot com 2011-08-19 16:57:57 UTC --- Fixed as of revision 177911.
[Bug tree-optimization/48739] [4.5/4.6/4.7 Regression] ICE in check_loop_closed_ssa_use() with -ftree-parallelize-loops=2 -fno-tree-dominator-opts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48739 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2011-08-19 16:59:00 UTC --- Created attachment 25055 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25055 gcc47-pr48739.patch Untested fix.
[Bug target/50099] ICE: internal compiler error: in extract_insn, at recog.c:2113 while building lttng-ust
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50099
Greta Yorsh Greta.Yorsh at arm dot com changed:
What|Removed |Added
CC||Greta.Yorsh at arm dot com
--- Comment #5 from Greta Yorsh Greta.Yorsh at arm dot com 2011-08-19
18:03:48 UTC ---
I can reproduce it with GCC 4.7 r177601 with -marm but not with -mthumb.
Here a smaller test case that seems related.
cat tst2.c
typedef signed char int8_t ;
typedef signed short int16_t;
typedef signed long int32_t;
typedef signed long long int64_t;
// doesn't ice if arg is unsigned
// doesn't ice if return is int32_t instead of int64_t
int64_t foo(int8_t * arg)
{
//int64_t temp_1;
int64_t temp_1;
temp_1 = arg[256]; // index must be 255 to ice!
return temp_1;
}
arm-none-eabi-gcc -O1 tst2.c
tst2.c: In function 'foo':
tst2.c:15:1: error: unrecognizable insn:
(insn 22 21 23 2 (set (subreg:SI (reg:DI 138 [ MEM[(int8_t *)arg_1(D) + 256B]
]) 0)
(sign_extend:SI (mem:QI (plus:SI (reg:SI 0 r0 [ arg ])
(const_int 256 [0x100])) [0 MEM[(int8_t *)arg_1(D) +
256B]+0 S1 A8]))) tst2.c:13 -1
(nil))
tst2.c:15:1: internal compiler error: in extract_insn, at recog.c:2115
-- Greta
[Bug fortran/50129] New: ICE on where statement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50129 Bug #: 50129 Summary: ICE on where statement Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: joost.vandevond...@pci.uzh.ch The following (invalid) testcase triggers and ICE: INTEGER :: I(3) WHERE (I2) ELSEWHERE ELSEWHERE (I1) END WHERE END Error: ELSEWHERE statement at (1) follows previous unmasked ELSEWHERE f951: internal compiler error: in gfc_enforce_clean_symbol_state, at fortran/symbol.c:3426
[Bug fortran/50130] New: ICE with invalid array slice
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50130 Bug #: 50130 Summary: ICE with invalid array slice Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: joost.vandevond...@pci.uzh.ch The following triggers an ICE integer, parameter :: a(10)=0 integer, parameter :: b(10)=a(1:10:0) END f951: internal compiler error: Floating point exception Please submit a full bug report,
[Bug libfortran/50105] [4.6/4.7 Regression] I/O with g6.5 - wrong number of ** shown
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50105 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P5 Severity|normal |minor --- Comment #9 from Tobias Burnus burnus at gcc dot gnu.org 2011-08-19 18:14:46 UTC --- For completeness: FORTRAN 77 had a similar wording at http://www.fortran.com/fortran/F77_std/rjcnf-13.html#sh-13.5.9 http://www.fortran.com/fortran/F77_std/rjcnf-13.html#sh-13.5.9.2.3 Bill is not convinced about Malcolm's answer: http://j3-fortran.org/pipermail/j3/2011-August/004606.html If I read it correctly, Bill thinks that one can read the standard such that ** is correct, but thinks that the standard is ambiguous and also allows ** which - according to his count - most compilers do and a user would expect. I think we will have at the end an interpretation request - thus, one might leave this item open until after the J3 meeting or better after the balloting of the J3 meeting edits. The next meeting is October 10-14, 2011.
[Bug fortran/50129] [4.6/4.7 Regression] ICE on where statement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50129 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-08-19 Summary|ICE on where statement |[4.6/4.7 Regression] ICE on ||where statement Ever Confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-08-19 18:16:58 UTC --- I don't get the ICE for gcc 4.4.6, 4.5.3, and 4.6.0 up to revision 162456. I get the ICE on 4.6.0 at revision 163718 and above, and on trunk.
[Bug fortran/50129] [4.6/4.7 Regression] ICE on where statement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50129
Mikael Morin mikael at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|unassigned at gcc dot |mikael at gcc dot gnu.org
|gnu.org |
--- Comment #2 from Mikael Morin mikael at gcc dot gnu.org 2011-08-19
18:26:34 UTC ---
I'm going to test this:
diff --git a/parse.c b/parse.c
index aab711c..9b11086 100644
--- a/parse.c
+++ b/parse.c
@@ -2778,6 +2778,7 @@ parse_where_block (void)
{
gfc_error (ELSEWHERE statement at %C follows previous
unmasked ELSEWHERE);
+ reject_statement ();
break;
}
[Bug fortran/50130] [4.6/4.7 Regression] ICE with invalid array slice
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50130 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-08-19 Summary|ICE with invalid array |[4.6/4.7 Regression] ICE |slice |with invalid array slice Ever Confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-08-19 18:29:25 UTC --- Confirmed with the same range of versions (4.4, 4.5, and early 4.6) giving pr50130.f90:2.30: integer, parameter :: b(10)=a(1:10:0) 1 Error: Illegal stride of zero at (1) and versions (late 4.6 and trunk) giving the floating point exception as for pr50129.
[Bug middle-end/50083] [4.7 regression] All 32-bit fortran tests fail on 32-bit Solaris
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50083 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011-08-19 AssignedTo|unassigned at gcc dot |ubizjak at gmail dot com |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from Uros Bizjak ubizjak at gmail dot com 2011-08-19 19:28:11 UTC --- Eh, usual problems with this kind of optimizations ;) I will look into it tomorrow...
[Bug fortran/50130] [4.6/4.7 Regression] ICE with invalid array slice
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50130 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #2 from kargl at gcc dot gnu.org 2011-08-19 19:43:13 UTC --- (gdb) bt #0 0x48c9efc5 in __gmp_exception () from /usr/local/lib/libgmp.so.10 #1 0x48c9effe in __gmp_divide_by_zero () from /usr/local/lib/libgmp.so.10 #2 0x48cb5120 in __gmpz_tdiv_qr () from /usr/local/lib/libgmp.so.10 #3 0x48cab4c7 in __gmpz_fdiv_q () from /usr/local/lib/libgmp.so.10 #4 0x080bf989 in gfc_ref_dimen_size (ar=0x0, dimen=1221515100, result=0xbfbfdf90, end=0xbfbfdf84) at ../../gcc4x/gcc/fortran/array.c:2047 #5 0x08131db8 in resolve_ref (expr=0x49091710) at ../../gcc4x/gcc/fortran/resolve.c:4576 #6 0x08132523 in resolve_variable (e=0x49091710) at ../../gcc4x/gcc/fortran/resolve.c:5007 #7 0x0812d018 in gfc_resolve_expr (e=0x49091710) at ../../gcc4x/gcc/fortran/resolve.c:6107 #8 0x080e5739 in gfc_reduce_init_expr (expr=0x49091710) at ../../gcc4x/gcc/fortran/expr.c:2609 #9 0x080e57e1 in gfc_match_init_expr (result=0xbfbfe254) at ../../gcc4x/gcc/fortran/expr.c:2650 #10 0x080d7ca4 in gfc_match_data_decl () at ../../gcc4x/gcc/fortran/decl.c:1997 #11 0x0811b637 in match_word (str=0xa Address 0xa out of bounds, subr=0x80d72a0 gfc_match_data_decl, old_locus=0xbfbfe2c0) at ../../gcc4x/gcc/fortran/parse.c:65 #12 0x0811bd11 in decode_statement () at ../../gcc4x/gcc/fortran/parse.c:283 #13 0x0811cf49 in next_statement () at ../../gcc4x/gcc/fortran/parse.c:724 #14 0x0811dffd in parse_spec (st=ST_DATA_DECL) at ../../gcc4x/gcc/fortran/parse.c:2576 #15 0x0811eecc in parse_progunit (st=ST_COMMON)
[Bug target/50131] New: Optimize x = -1 with or for -O
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50131
Bug #: 50131
Summary: Optimize x = -1 with or for -O
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
CC: ubiz...@gmail.com
[hjl@gnu-6 rtm-1]$ cat x.c
int
foo1 ()
{
return -1;
}
short
foo2 ()
{
return -1;
}
long long
foo3 ()
{
return -1;
}
[hjl@gnu-6 rtm-1]$ gcc -S -Os x.c
[hjl@gnu-6 rtm-1]$ cat x.s
.filex.c
.text
.globlfoo1
.typefoo1, @function
foo1:
.LFB0:
.cfi_startproc
orl$-1, %eax
ret
.cfi_endproc
.LFE0:
.sizefoo1, .-foo1
.globlfoo2
.typefoo2, @function
foo2:
.LFB1:
.cfi_startproc
orl$-1, %eax
ret
.cfi_endproc
.LFE1:
.sizefoo2, .-foo2
.globlfoo3
.typefoo3, @function
foo3:
.LFB2:
.cfi_startproc
orq$-1, %rax
ret
.cfi_endproc
.LFE2:
.sizefoo3, .-foo3
.identGCC: (GNU) 4.6.0 20110603 (Red Hat 4.6.0-10)
.section.note.GNU-stack,,@progbits
[hjl@gnu-6 rtm-1]$ gcc -S -O2 x.c
[hjl@gnu-6 rtm-1]$ cat x.s
.filex.c
.text
.p2align 4,,15
.globlfoo1
.typefoo1, @function
foo1:
.LFB0:
.cfi_startproc
movl$-1, %eax
ret
.cfi_endproc
.LFE0:
.sizefoo1, .-foo1
.p2align 4,,15
.globlfoo2
.typefoo2, @function
foo2:
.LFB1:
.cfi_startproc
movl$-1, %eax
ret
.cfi_endproc
.LFE1:
.sizefoo2, .-foo2
.p2align 4,,15
.globlfoo3
.typefoo3, @function
foo3:
.LFB2:
.cfi_startproc
movq$-1, %rax
ret
.cfi_endproc
.LFE2:
.sizefoo3, .-foo3
.identGCC: (GNU) 4.6.0 20110603 (Red Hat 4.6.0-10)
.section.note.GNU-stack,,@progbits
[hjl@gnu-6 rtm-1]$
I was expecting or for -O.
[Bug target/50131] Optimize x = -1 with or for -O
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50131 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2011-08-19 20:58:00 UTC --- There are 1273 movl $0x, and 924 movq 0x, in cc1plus. This change can reduce cc1plus size by 6242 bytes.
[Bug middle-end/49721] convert_memory_address_addr_space may generate invalid new insns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49721 --- Comment #26 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2011-08-19 21:18:06 UTC --- Author: hjl Date: Fri Aug 19 21:18:03 2011 New Revision: 177914 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=177914 Log: Permute conversion and addition of constant for zero-extend. gcc/ 2011-08-19 H.J. Lu hongjiu...@intel.com PR middle-end/49721 * explow.c (convert_memory_address_addr_space): Also permute the conversion and addition of constant for zero-extend. gcc/testsuite/ 2011-08-19 H.J. Lu hongjiu...@intel.com PR middle-end/49721 * gfortran.dg/pr49721-1.f: New. * gfortran.fortran-torture/compile/pr49721-1.f: Likewise. Added: trunk/gcc/testsuite/gfortran.dg/pr49721-1.f trunk/gcc/testsuite/gfortran.fortran-torture/compile/pr49721-1.f Modified: trunk/gcc/ChangeLog trunk/gcc/explow.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/50130] [4.6/4.7 Regression] ICE with invalid array slice
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50130 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-invalid-code CC||burnus at gcc dot gnu.org, ||tkoenig at gcc dot gnu.org Target Milestone|--- |4.6.2 --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2011-08-19 21:19:50 UTC --- Working: GCC 4.6-trunk 2010-07-16-r162255 Failing: GCC 4.6-trunk 2010-08-28-r163612 array.c's gfc_ref_dimen_size contains: mpz_div (*result, *result, stride); /* Zero stride caught earlier. */ The comment is correct: The ICE comes already one line earlier ... Seemingly caused by Rev. 163041: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163041 2010-08-09 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/44235 * array.c (gfc_ref_dimen_size): Add end argument. If end is non-NULL, calculate it. (ref_size): Adjust call to gfc_ref_dimen_size. (gfc_array_dimen_size): Likewise. (gfc_array_res_shape): Likewise. * gfortran.h: Adjust prototype for gfc_ref_dimen_size. * resolve.c (resolve_array_ref): For stride not equal to -1, fill in the lowest possible end. The problem seems to be the following in resolve_array_ref: /* Fill in the upper bound, which may be lower than the specified one for something like a(2:10:5), which is identical to a(2:7:5). Only relevant for strides not equal to one. */ [...] if (gfc_ref_dimen_size (ar, i, size, end) == SUCCESS) [...] if (!ar-as-cray_pointee compare_spec_to_ref (ar) == FAILURE) In the call to gfc_ref_dimen_size one has the division by zero. With the call to compare_spec_to_ref one reaches via check_dimension the Illegal stride of zero check, which obviously comes too late.
[Bug debug/50132] New: [4.7 Regression] ICE: in maybe_record_trace_start, at dwarf2cfi.c:2234 with -fno-asynchronous-unwind-tables and long double
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50132 Bug #: 50132 Summary: [4.7 Regression] ICE: in maybe_record_trace_start, at dwarf2cfi.c:2234 with -fno-asynchronous-unwind-tables and long double Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 25056 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25056 reduced testcase Compiler output: $ gcc -Os -fno-asynchronous-unwind-tables -g testcase.c testcase.c: In function 'foo': testcase.c:7:1: internal compiler error: in maybe_record_trace_start, at dwarf2cfi.c:2234 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Tested revisions: r177889 - crash r177543 - crash r173150 - OK
[Bug tree-optimization/50133] New: [4.7 Regression] ICE: SIGSEGV in vect_finish_stmt_generation (gimple.h:4821) with -ftree-vectorize -fno-tree-loop-im
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50133 Bug #: 50133 Summary: [4.7 Regression] ICE: SIGSEGV in vect_finish_stmt_generation (gimple.h:4821) with -ftree-vectorize -fno-tree-loop-im Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 25057 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25057 testcase (gcc.dg/pr46184.c) Compiler output: $ gcc -O -ftree-vectorize -fno-tree-loop-im testcase.c ==6443== Invalid read of size 8 ==6443==at 0xB053E1: vect_finish_stmt_generation(gimple_statement_d*, gimple_statement_d*, gimple_stmt_iterator*) (gimple.h:4821) ==6443==by 0xB05C8E: vect_init_vector(gimple_statement_d*, tree_node*, tree_node*, gimple_stmt_iterator*) (tree-vect-stmts.c:1082) ==6443==by 0xB07625: vectorizable_load(gimple_statement_d*, gimple_stmt_iterator*, gimple_statement_d**, _slp_tree*, _slp_instance*) (tree-vect-stmts.c:4626) ==6443==by 0xB1268C: vect_transform_stmt(gimple_statement_d*, gimple_stmt_iterator*, bool*, _slp_tree*, _slp_instance*) (tree-vect-stmts.c:5197) ==6443==by 0xB2270B: vect_transform_loop(_loop_vec_info*) (tree-vect-loop.c:5332) ==6443==by 0xB2F678: vectorize_loops() (tree-vectorizer.c:205) ==6443==by 0x8A6046: execute_one_pass(opt_pass*) (passes.c:2063) ==6443==by 0x8A63B4: execute_pass_list(opt_pass*) (passes.c:2118) ==6443==by 0x8A63C6: execute_pass_list(opt_pass*) (passes.c:2119) ==6443==by 0x8A63C6: execute_pass_list(opt_pass*) (passes.c:2119) ==6443==by 0x9FE69D: tree_rest_of_compilation(tree_node*) (tree-optimize.c:420) ==6443==by 0x653A55: cgraph_expand_function(cgraph_node*) (cgraphunit.c:1797) ==6443==by 0x6557BA: cgraph_optimize() (cgraphunit.c:1856) ==6443==by 0x655E49: cgraph_finalize_compilation_unit() (cgraphunit.c:1310) ==6443==by 0x537367: c_write_global_declarations() (c-decl.c:9881) ==6443==by 0x99C191: toplev_main(int, char**) (toplev.c:564) ==6443==by 0x6734D2C: (below main) (in /lib64/libc-2.12.2.so) ==6443== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==6443== testcase.c: In function 'foo': testcase.c:4:1: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Tested revisions: r177889 - crash r177543 - crash r173150 - OK
[Bug c++/50134] New: -Wmissing-prototypes doesn't work for C++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50134
Bug #: 50134
Summary: -Wmissing-prototypes doesn't work for C++
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
[hjl@gnu-33 gcc]$ cat x.c
int
foo (int x)
{
return x;
}
[hjl@gnu-33 gcc]$ ./xgcc -B./ -S -O -Wmissing-prototypes x.c
x.c:2:1: warning: no previous prototype for ‘foo’ [-Wmissing-prototypes]
[hjl@gnu-33 gcc]$ ./g++ -B./ -S -O -Wmissing-prototypes x.c
cc1plus: warning: command line option ‘-Wmissing-prototypes’ is valid
for Ada/AdaWhy/C/ObjC but not for C++ [enabled by default]
[hjl@gnu-33 gcc]$ ./g++ -B./ -S -O x.c
[hjl@gnu-33 gcc]$ ./g++ -B./ -Wall -S -O x.c
[hjl@gnu-33 gcc]$
[Bug middle-end/48600] [4.6/4.7 Regression] ICE when using cold attribute
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48600 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added AssignedTo|unassigned at gcc dot |hubicka at gcc dot gnu.org |gnu.org | --- Comment #9 from Jan Hubicka hubicka at gcc dot gnu.org 2011-08-19 22:16:41 UTC --- mine
[Bug rtl-optimization/49936] [4.7 Regression] IRA handles CANNOT_CHANGE_MODE_CLASS poorly, + spills to memory on 4.7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49936 --- Comment #5 from Vladimir Makarov vmakarov at gcc dot gnu.org 2011-08-19 22:17:29 UTC --- Author: vmakarov Date: Fri Aug 19 22:17:26 2011 New Revision: 177916 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=177916 Log: 2011-08-19 Vladimir Makarov vmaka...@redhat.com PR rtl-optimization/49936 * ira.c (ira_init_register_move_cost): Ignore too small subclasses for calculation of max register move costs. Modified: trunk/gcc/ChangeLog trunk/gcc/ira.c
[Bug middle-end/50083] [4.7 regression] All 32-bit fortran tests fail on 32-bit Solaris
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50083 --- Comment #2 from Uros Bizjak ubizjak at gmail dot com 2011-08-19 22:21:53 UTC --- Created attachment 25058 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25058 Proposed patch to fallback to lround call I can't trigger the problem on Linux, can you please test attached patch - or eventually provide a testcase with all necessary compile flags.
[Bug tree-optimization/45978] [4.6 Regression] bogus array subscript is above array bounds warning in extremely simple code with no loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45978 --- Comment #8 from torsten at debian dot org 2011-08-19 22:54:11 UTC --- Created attachment 25059 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25059 An obviously correct example that triggers the bug. (In reply to comment #7) GCC 4.6.1 is being released. I just searched for this problem due to a bug report that SWIG causes out of bounds array accesses: https://sourceforge.net/tracker/?func=detailatid=101645aid=3394790group_id=1645 It turns out that the generated code is similar to the trivial example that I attached. Perhaps this makes it easier to track down the bug.
[Bug debug/50132] [4.7 Regression] ICE: in maybe_record_trace_start, at dwarf2cfi.c:2234 with -fno-asynchronous-unwind-tables and long double
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50132 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug tree-optimization/50133] [4.7 Regression] ICE: SIGSEGV in vect_finish_stmt_generation (gimple.h:4821) with -ftree-vectorize -fno-tree-loop-im
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50133 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug tree-optimization/48739] [4.5/4.6/4.7 Regression] ICE in check_loop_closed_ssa_use() with -ftree-parallelize-loops=2 -fno-tree-dominator-opts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48739
--- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2011-08-19
23:04:36 UTC ---
(In reply to comment #1)
Simplified testcase:
/* PR tree-optimization/48739 */
/* { dg-do compile } */
/* { dg-options -O1 -ftree-parallelize-loops=2 -fno-tree-dominator-opts } */
extern int g;
extern void bar (void);
int
foo (int x)
{
int a, b, *c = (int *) 0;
for (a = 0; a 10; ++a)
{
bar ();
for (b = 0; b 5; ++b)
{
x = 0;
c = x;
g = 1;
}
}
*c = x;
for (x = 0; x != 10; x++)
;
return g;
}
Started with http://gcc.gnu.org/viewcvs?root=gccview=revrev=149206
(before that the empty loop would be just removed).
The bug seems to be that parloops pass requests TODO_rebuild_alias which
changes x from TREE_ADDRESSABLE to a gimple var, but we are in loop closed SSA
form at that point and nothing ensures that the optimized variable is put into
loop closed SSA form.
The bug would be that TODO_rebuild_alias does a TODO_update_address_taken.
But really parloops should be re-architected to not require a
TODO_rebuild_alias ... (it isn't required anymore for correctness anyway)
[Bug c/36489] [4.3 Regression] Warning initialized field overwritten wrongly triggers with multidimensional arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36489 Arun Chandrasekaran visionofarun at gmail dot com changed: What|Removed |Added CC||visionofarun at gmail dot ||com --- Comment #9 from Arun Chandrasekaran visionofarun at gmail dot com 2011-08-19 23:04:24 UTC --- The bug is still persistent in GCC 4.5.2.
[Bug fortran/50129] [4.6/4.7 Regression] ICE on where statement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50129 --- Comment #3 from Mikael Morin mikael at gcc dot gnu.org 2011-08-19 23:20:35 UTC --- Author: mikael Date: Fri Aug 19 23:20:30 2011 New Revision: 177918 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=177918 Log: 2011-08-19 Mikael Morin mikael.mo...@sfr.fr PR fortran/50129 * parse.c (parse_where): Undo changes after emitting an error. 2011-08-19 Mikael Morin mikael.mo...@sfr.fr PR fortran/50129 * gfortran.dg/where_3.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/where_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/parse.c trunk/gcc/testsuite/ChangeLog
[Bug c++/40831] g++ generated symbols for cloned function that be demangled.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40831 Cary Coutant ccoutant at gcc dot gnu.org changed: What|Removed |Added Attachment #23439|0 |1 is obsolete|| --- Comment #11 from Cary Coutant ccoutant at gcc dot gnu.org 2011-08-20 00:54:56 UTC --- Created attachment 25060 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25060 Updated patch to demangle cloned function symbols This patch generalizes the clone suffix recognition, so it accepts a series of suffixes of the form [.clonetype][.nnn]
[Bug libgomp/46967] lots of testsuite failures with libgomp on hppa-hp-hpux11.31
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46967 --- Comment #7 from The Written Word bugzilla-gcc at thewrittenword dot com 2011-08-20 03:34:48 UTC --- (In reply to comment #4) This should be fixed. Albert, can you confirm that the pthread active changes fixed this problem? Regarding comment #3, look at the libgomp test log file to see why the tests are failing on alphaev68-dec-osf5.1a. I'm certain the problem is different from the hppa2.0w-hp-hpux11.31 issue, so a new PR should be opened. It should be fixed in 4.4.6? What revision fixed the problem?
[Bug c/50135] New: Loop optimization.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50135 Bug #: 50135 Summary: Loop optimization. Classification: Unclassified Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: bratsi...@gmail.com May be single-cycle should translate that: C code: for(unsigned int i=0; i123456; i++) or for(unsigned int i=123456; i0; i--) Assembler code: movq 123456, %rcx L0: some code there loop LO
[Bug c/50136] New: Loop inc/dec optimization.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50136 Bug #: 50136 Summary: Loop inc/dec optimization. Classification: Unclassified Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: bratsi...@gmail.com Maybe shoud use inc and dec, than sub $1, %ebx? GCC translate this C code: unsigned int i; scanf(%u, i); for(unsigned int qwe=i; qwe0; qwe--) printf(fg); Into this Assembler code: leaq12(%rsp), %rsi xorl%eax, %eax movl$.LC0, %edi call__isoc99_scanf movl12(%rsp), %ebx testl%ebx, %ebx je.L2 .p2align 4,,10 .p2align 3 .L4: xorl%eax, %eax movl$.LC1, %edi callprintf subl$1, %ebx ;This not good, dec %ebx is better jne.L4
