[Bug target/46880] [4.4/4.5 Regression] generating of shufpd is broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46880 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-17 08:01:17 UTC --- Fixed.
[Bug middle-end/45852] volatile structs are broken!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45852 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-17 08:01:41 UTC --- Fixed for 4.4+.
[Bug fortran/46874] [OpenMP] ICE in gfc_conv_descriptor_data_get, at fortran/trans-array.c:147
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46874 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-17 08:02:05 UTC --- Fixed.
[Bug rtl-optimization/46865] [4.3 Regression] Using -save-temps (or ccache, distcc) produces different results with multiline macros containing asm code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46865 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Known to work||4.4.6, 4.5.3 Summary|[4.3/4.4/4.5 Regression]|[4.3 Regression] Using |Using -save-temps (or |-save-temps (or ccache, |ccache, distcc) produces|distcc) produces different |different results with |results with multiline |multiline macros containing |macros containing asm code |asm code| --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-17 08:05:03 UTC --- Fixed for 4.4+.
[Bug target/47201] [4.5 Regression] ICE: SIGSEGV in adjust_mems (var-tracking.c:814) with -O -fPIC -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47201 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-17 08:05:40 UTC --- Fixed.
[Bug c/47150] [4.5 Regression] ICE in gimplify_expr at gimplify.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47150 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-17 08:06:04 UTC --- Fixed.
[Bug tree-optimization/43655] [4.5 Regression] -ftree-ter causes FAIL: g++.old-deja/g++.law/temps5.C execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43655 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #13 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-17 08:06:36 UTC --- Fixed.
[Bug debug/46893] [4.5 Regression] ICE: in trunc_int_for_mode, at explow.c:56 with -O -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46893 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-17 08:07:12 UTC --- Fixed.
[Bug rtl-optimization/46804] [4.5 Regression] gfortran.dg/char_cshift_2.f90 FAILs with -fregmove
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46804 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-17 08:08:05 UTC --- Fixed.
[Bug tree-optimization/46864] [4.5 Regression] ICE: verify_stmts failed: statement marked for throw, but doesn't with -fnon-call-exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46864 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-17 08:26:04 UTC --- Fixed.
[Bug target/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #74 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-17 08:26:29 UTC --- Fixed.
[Bug fortran/46416] libquadmath: missing functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46416 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-17 08:27:28 UTC --- Fixed.
[Bug fortran/46402] libquadmath: Add fmalq
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46402 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-17 08:27:53 UTC --- Fixed.
[Bug fortran/47327] New: Documentation: Link to GCC Errors and Warnings options broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47327 Summary: Documentation: Link to GCC Errors and Warnings options broken Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: thenl...@users.sourceforge.net The GNU Fortran page (2.4 Options to request or suppress errors and warnings) http://gcc.gnu.org/onlinedocs/gfortran/Error-and-Warning-Options.html contains a link to (Options to Request or Suppress Errors and Warnings) leading to http://gcc.gnu.org/onlinedocs/gcc/Error-and-Warning-Options.html#Error-and-Warning-Options but this page does not exist.
[Bug fortran/46817] Missing copyright header in libquadmath/*.[hc]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46817 --- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org 2011-01-17 09:14:47 UTC --- Author: burnus Date: Mon Jan 17 09:14:41 2011 New Revision: 168892 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168892 Log: 2011-01-17 Tobias Burnus bur...@net-b.de PR fortran/46817 * quadmath-imp.h: Refer to libquadmath not ot libiberty, bump copyright year and use /**/ instead of // comments. * quadmath.h: Ditto. * quadmath-weak.h: Ditto. * quadmath_io.c: Ditto. Modified: trunk/libquadmath/ChangeLog trunk/libquadmath/quadmath-imp.h trunk/libquadmath/quadmath.h trunk/libquadmath/quadmath_io.c trunk/libquadmath/quadmath_weak.h
[Bug fortran/46817] Missing copyright header in libquadmath/*.[hc]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46817 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org 2011-01-17 09:15:13 UTC --- FIXED
[Bug fortran/45586] [4.6 Regression] ICE non-trivial conversion at assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #26 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-17
10:08:13 UTC ---
(In reply to comment #24)
(In reply to comment #23)
We could do the analysis that fixed PR 45777 here, I just don't know
where :-)
Could somebody point me to the right place (I presume somewhere in trans-*)?
$ grep RESTRICT *
ChangeLog-2009:instead set DECL_RESTRICTED_P on affected decls.
trans-decl.c:DECL_RESTRICTED_P (decl) = 1;
trans-types.c: prvoid_type_node = build_qualified_type (pvoid_type_node,
TYPE_QUAL_RESTRICT);
trans-types.c:TYPE_QUAL_RESTRICT);
trans-types.c:type = build_qualified_type (type, TYPE_QUAL_RESTRICT);
trans-types.c:arraytype = build_qualified_type (arraytype,
TYPE_QUAL_RESTRICT);
trans-types.c:type = build_qualified_type (type, TYPE_QUAL_RESTRICT);
$
then if you look at those places, they are guarded with a if (restricted)
condition, so the places you are looking for are those of calls to functions
expecting an argument named restricted (gfc_build_array_type,
gfc_get_nodesc_array_type).
However, it doesn't look that easy.
If I understand the thing correctly, in case you have an entity with a pointer
or target attribute, you have to build a variant of its base type without the
restrict attribute. That seems easy. Less easy is that you have to build a
variant type without the restrict attribute for each of it's sub-components
too.
That is, for
!
type foo
integer, allocatable :: bar(:)
end type foo
type(foo) :: x
type(foo), pointer :: y
call baz (x, y)
!
The type of baz's first actual argument (namely x) is struct foo * restrict
but the type of baz's second actual argument (namely y) is not struct foo *.
typeof(x) ==
struct foo_restrict {
struct integer_array {
struct array_bounds {
int lbound, ubound, stride;
} bounds [];
...
integer * restrict data;
} bar;
} * restrict
whereas
typeof(y) ==
struct foo_norestrict {
struct integer_array {
struct array_bounds {
int lbound, ubound, stride;
} bounds [];
...
integer * data;
} bar;
} *
Note that the data member has lost the restrict too. Thus, when creating such
pointer qualified types, one should take care not to update the
sym-backend_decl of the derived type as they are different. That looks like a
substantial rework.
Or maybe drop restrict all together on the type for correctness.
Indeed when we introduced the restrict handling to the Fortran frontend
we thought that the above case would not happen, thus that the testcase
in question would be not a valid Fortran program. At the moment
we probably even could generate a testcase that generates wrong-code
(when the ICE silences itself with release-checking). This means that
simply trying to make it not ICE is probably wrong and simply hides
the real issue (which the ICE shows).
It is, btw, a sign of bad Fortran language design and makes the point
of the pointer/target attributes moot.
What we could do is drop restrict qualifications for all aggregate
types. At least such funny games do not seem possible with mere
toplevel arrays or scalars, right?
By the way, does the middle-end support creating a variant of a type with a
sub-component restrict (un)qualified ?
No. For type variants all the fields are usually shared, you'd have to
create a deep copy.
[Bug c++/47326] ICE in tsubst_copy (triggered by dependency of return type on parameter pack size)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47326 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2011-01-17 10:13:14 UTC --- Let's add Jason in CC for this one too.
[Bug middle-end/39838] [4.3/4.4/4.5/4.6 regression] unoptimal code for two simple loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39838 --- Comment #9 from Zdenek Dvorak rakdver at gcc dot gnu.org 2011-01-17 11:04:22 UTC --- UGH. Everything involving ivtmp.12 is a waste of time. We really just need to realize that D1976_16 is D1971_10 + 4 which avoids all the nonsense with ivtmp.12 and I *think* would restore the quality of this code. I don't know enough about the current ivopts code to prototype this and verify that such a change would restore the quality of this code. actually, ivopts know that D1976_16 is D1971_10 + 4; however, since both D1971_10 = ivtmp.12 - 4; and D1971_10 = i 2; have the same complexity, it arbitrarily decides to use the latter. The problem is in ivopts deciding to create ivtmp.12 at all. However, this will be somewhat hard to avoid, since locally, replacing D1976_16 (= i 2 + 4) by a new iv is a correct decision (it replaces addition and shift by a single addition). Ideally, ivopts should recognize that D1976_16 and D1971_10 are used for memory addressing and use the appropriate addressing modes ([D.1969_8 + 4*i + 4] instead of [D.1972_11]). However, that also fails since ivopts only recognize the memory references whose addresses are affine ivs (which is not the case here, as we cannot prove that D.1969_8 is invariant in the loop).
[Bug rtl-optimization/47299] [4.6 Regression] Widening multiply optimization generates bad code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47299 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 #4 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-17 11:25:00 UTC --- Created attachment 22994 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22994 gcc46-pr47299.patch Untested fix.
[Bug fortran/47327] Documentation: Link to GCC Errors and Warnings options broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47327 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Keywords||documentation Status|UNCONFIRMED |NEW Last reconfirmed||2011.01.17 11:29:47 Ever Confirmed|0 |1 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-01-17 11:29:47 UTC --- should probably be http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html
[Bug target/46655] invalid '.line 0' directive emitted with -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46655 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc-p ||atches/2010-11/msg02928.htm ||l Severity|normal |major
[Bug tree-optimization/47286] Invalid code when using register ... asm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47286 --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-17 11:31:15 UTC --- Author: rguenth Date: Mon Jan 17 11:31:10 2011 New Revision: 168894 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168894 Log: 2011-01-17 Richard Guenther rguent...@suse.de Backport from mainline PR tree-optimization/47286 * tree-ssa-structalias.c (new_var_info): Register variables are global. * gcc.dg/tree-ssa/pr47286.c: New testcase. PR tree-optimization/44592 * tree-ssa-ccp.c (gimplify_and_update_call_from_tree): Copy from trunk. * gfortran.dg/pr44592.f90: New testcase. Added: branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/tree-ssa/pr47286.c branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/pr44592.f90 Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/testsuite/ChangeLog branches/gcc-4_5-branch/gcc/tree-ssa-ccp.c branches/gcc-4_5-branch/gcc/tree-ssa-structalias.c
[Bug middle-end/44592] [4.5 Regression] wrong code at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44592 --- Comment #16 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-17 11:31:14 UTC --- Author: rguenth Date: Mon Jan 17 11:31:10 2011 New Revision: 168894 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168894 Log: 2011-01-17 Richard Guenther rguent...@suse.de Backport from mainline PR tree-optimization/47286 * tree-ssa-structalias.c (new_var_info): Register variables are global. * gcc.dg/tree-ssa/pr47286.c: New testcase. PR tree-optimization/44592 * tree-ssa-ccp.c (gimplify_and_update_call_from_tree): Copy from trunk. * gfortran.dg/pr44592.f90: New testcase. Added: branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/tree-ssa/pr47286.c branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/pr44592.f90 Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/testsuite/ChangeLog branches/gcc-4_5-branch/gcc/tree-ssa-ccp.c branches/gcc-4_5-branch/gcc/tree-ssa-structalias.c
[Bug testsuite/39807] [4.3 Regression] Reporting of testsuite failures are messed up when using -j
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39807 --- Comment #17 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-01-17 11:33:37 UTC --- Probably WONTFIX at this point?
[Bug tree-optimization/47286] Invalid code when using register ... asm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47286 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||4.5.3 Resolution||FIXED Target Milestone|--- |4.5.3 --- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-17 11:33:48 UTC --- Fixed.
[Bug middle-end/44592] [4.5 Regression] wrong code at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44592 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||4.5.3, 4.6.0 Resolution||FIXED Known to fail||4.5.2 --- Comment #17 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-17 11:34:31 UTC --- Fixed.
[Bug middle-end/45422] [4.6 Regression] compile time increases 3x.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45422 Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch changed: What|Removed |Added Last reconfirmed|2010-08-29 09:25:52 |2011-01-17 9:25:52 --- Comment #27 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-01-17 11:38:36 UTC --- timings with current trunk (release checking). out.4_3 TOTAL : 34.620.43 35.27 837034 kB out.4_5 TOTAL : 45.300.70 46.02 897447 kB out.trunk TOTAL : 165.890.99 166.971743679 kB so time is up by 5x memory 2x relative to 4.3.
[Bug target/18580] vectorizer failures (max, unaligned)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18580 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Comment #8 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-01-17 11:40:22 UTC --- This is now parameterized in the testsuite.
[Bug tree-optimization/45967] [4.5 Regression] gcc-4.5.x optimizes code with side-effects away
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45967
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Component|rtl-optimization|tree-optimization
Known to fail||4.5.2
--- Comment #8 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-17
11:44:11 UTC ---
The patch is quite big and a backport is nothing for the faint-hearted. Do not
hold your breath.
The underlying problem is present since ever btw, and 4.4 can be tricked
into miscompiling with the usual avoid-empty-points-to-sets trick
(conditionally assign (not) to the pointer, thus add something else
to the set):
extern void abort (void);
int b;
void
foo (void *p_, int *q)
{
int *p;
int i;
for (i = 0; i sizeof(int *); ++i)
((char *)p)[i] = ((char *)p_)[i];
if (b)
p = q;
*p = 1;
}
int main()
{
int i = 0, j;
int *p = i;
foo (p, j);
if (i != 1)
abort ();
return 0;
}
I'll add some more testcases.
[Bug tree-optimization/45967] [4.5 Regression] gcc-4.5.x optimizes code with side-effects away
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45967 --- Comment #9 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-17 11:50:50 UTC --- Author: rguenth Date: Mon Jan 17 11:50:47 2011 New Revision: 168896 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168896 Log: 2011-01-17 Richard Guenther rguent...@suse.de PR tree-optimization/45967 * gcc.dg/torture/pr45967-2.c: New testcase. * gcc.dg/torture/pr45967-3.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/torture/pr45967-2.c trunk/gcc/testsuite/gcc.dg/torture/pr45967-3.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug target/46880] [4.4/4.5 Regression] generating of shufpd is broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46880 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Known to work||4.4.6, 4.5.3 Target Milestone|4.6.0 |4.4.6 Known to fail|4.4.6 |4.4.5
[Bug libfortran/47322] [4.6 regression] libquadmath breaks bootstrap on x86_64-unknown-freebsd8.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47322 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.0
[Bug tree-optimization/47316] devirtualize calls to virtual methods that are never further overriden
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47316
--- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2011-01-17
12:02:02 UTC ---
(In reply to comment #1)
Actually better solution would be function and type attributes, hinting the
function is never overriden.
C++0x has override control features:
struct B {
virtual void f() const final;
};
As I've commented on several PRs, any work in this area should be done in line
with C++0x, not with GNU-specific attributes
[Bug rtl-optimization/47270] [4.4/4.5/4.6 Regression] GCC produces unnecessary/wrong code on -O2 and -O3 levels
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47270 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-17 12:06:11 UTC --- Why do you think it is wrong? If %esi is non-zero upon entry, then it is just moved to %eax and back, so it isn't changed, if it was zero upon entry, then 0 is loaded into it. The reason for the extra code is that pre attempts to optimize it (register vars are not SSA vars), so we get at *.optimized: int prephitmp.4; int r.0; bb 2: r.0_1 = r; if (r.0_1 != 0) goto bb 3; else goto bb 4; bb 3: __asm__(sar %0 : =r r : 0 r.0_1); prephitmp.4_2 = r; bb 4: # prephitmp.4_8 = PHI 0(2), prephitmp.4_2(3) __asm__(sar %0 : =r r : 0 prephitmp.4_8); and RTL optimizations aren't able to undo that. I doubt anything can be done about this easily, with -fno-tree-pre you get your expected output.
[Bug middle-end/47313] [4.6 Regression] ICE: PHI argument is not a GIMPLE value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47313 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 #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-17 12:06:36 UTC --- For some reason IPA-SRA breaks it. Looking at it.
[Bug tree-optimization/47316] devirtualize calls to virtual methods that are never further overriden
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47316 --- Comment #3 from Martin Jambor jamborm at gcc dot gnu.org 2011-01-17 12:20:09 UTC --- Actually, thanks for filing the bug. Devirtualization and other optimizations (such as struct-reorg) based on type escape analysis are a debated issue and it is nice to know users have interest in it.
[Bug target/46655] invalid '.line 0' directive emitted with -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46655 --- Comment #15 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-01-17 12:35:26 UTC --- Author: ebotcazou Date: Mon Jan 17 12:35:21 2011 New Revision: 168897 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168897 Log: PR target/46655 * xcoffout.c (ASM_OUTPUT_LINE): Output line only if positive, and only if = USHRT_MAX in 32-bit mode. Modified: trunk/gcc/ChangeLog trunk/gcc/xcoffout.c
[Bug fortran/47327] Documentation: Link to GCC Errors and Warnings options broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47327
Tobias Burnus burnus at gcc dot gnu.org changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2011-01-17
12:37:18 UTC ---
Lightly tested patch:
--- a/gcc/fortran/invoke.texi
+++ b/gcc/fortran/invoke.texi
@@ -865,7 +865,7 @@ off via @option{-Wno-align-commons}. See also
@option{-falign-commons}.
Turns all warnings into errors.
@end table
-@xref{Error and Warning Options,,Options to Request or Suppress Errors and
+@xref{Warning Options,,Options to Request or Suppress Errors and
Warnings, gcc,Using the GNU Compiler Collection (GCC)}, for information on
more options offered by the GBE shared by @command{gfortran}, @command{gcc}
and other GNU compilers.
[Bug target/46655] invalid '.line 0' directive emitted with -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46655 --- Comment #16 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-01-17 12:37:00 UTC --- Author: ebotcazou Date: Mon Jan 17 12:36:55 2011 New Revision: 168898 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168898 Log: PR target/46655 * xcoffout.c (ASM_OUTPUT_LINE): Output line only if positive, and only if = USHRT_MAX in 32-bit mode. Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/xcoffout.c
[Bug target/46655] invalid '.line 0' directive emitted with -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46655 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.5.3 --- Comment #17 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-01-17 12:38:51 UTC --- Fixed in 4.5.x and later.
[Bug target/47318] _mm256_maskstore_pd has wrong prototype
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47318 --- Comment #2 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2011-01-17 12:47:23 UTC --- Author: hjl Date: Mon Jan 17 12:47:21 2011 New Revision: 168899 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168899 Log: Correct mask operand for AVX mask load/store. gcc/ 2011-01-17 H.J. Lu hongjiu...@intel.com PR target/47318 * config/i386/avxintrin.h (_mm_maskload_pd): Change mask to __m128i. (_mm_maskstore_pd): Likewise. (_mm_maskload_ps): Likewise. (_mm_maskstore_ps): Likewise. (_mm256_maskload_pd): Change mask to __m256i. (_mm256_maskstore_pd): Likewise. (_mm256_maskload_ps): Likewise. (_mm256_maskstore_ps): Likewise. * config/i386/i386-builtin-types.def: Updated. (ix86_expand_special_args_builtin): Likewise. * config/i386/i386.c (bdesc_special_args): Update __builtin_ia32_maskloadpd, __builtin_ia32_maskloadps, __builtin_ia32_maskloadpd256, __builtin_ia32_maskloadps256, __builtin_ia32_maskstorepd, __builtin_ia32_maskstoreps, __builtin_ia32_maskstorepd256 and __builtin_ia32_maskstoreps256. * config/i386/sse.md (avx_maskloadssemodesuffixavxmodesuffix): Use avxpermvecmode on mask register. (avx_maskstoressemodesuffixavxmodesuffix): Likewise. gcc/testsuite/ 2011-01-17 H.J. Lu hongjiu...@intel.com PR target/47318 * gcc.target/i386/avx-vmaskmovpd-1.c: New. * gcc.target/i386/avx-vmaskmovpd-2.c: Likewise. * gcc.target/i386/avx-vmaskmovps-1.c: Likewise. * gcc.target/i386/avx-vmaskmovps-1.c: Likewise. * gcc.target/i386/avx-vmaskmovpd-256-1.c (avx_test): Load mask as __m256i. * gcc.target/i386/avx-vmaskmovpd-256-2.c (avx_test): Likewise. * gcc.target/i386/avx-vmaskmovps-256-1.c (avx_test): Likewise. * gcc.target/i386/avx-vmaskmovps-256-2.c (avx_test): Likewise. Added: trunk/gcc/testsuite/gcc.target/i386/avx-vmaskmovpd-1.c trunk/gcc/testsuite/gcc.target/i386/avx-vmaskmovpd-2.c trunk/gcc/testsuite/gcc.target/i386/avx-vmaskmovps-1.c trunk/gcc/testsuite/gcc.target/i386/avx-vmaskmovps-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/avxintrin.h trunk/gcc/config/i386/i386-builtin-types.def trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/sse.md trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/i386/avx-vmaskmovpd-256-1.c trunk/gcc/testsuite/gcc.target/i386/avx-vmaskmovpd-256-2.c trunk/gcc/testsuite/gcc.target/i386/avx-vmaskmovps-256-1.c trunk/gcc/testsuite/gcc.target/i386/avx-vmaskmovps-256-2.c
[Bug fortran/45586] [4.6 Regression] ICE non-trivial conversion at assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 --- Comment #27 from Mikael Morin mikael at gcc dot gnu.org 2011-01-17 13:01:23 UTC --- (In reply to comment #25) Maybe it would be better to set the inherited pointer and target attributes much earlier, in gfc_variable_attr. With a bit of luck, things would then work automatically. If you mean set the gfc_component.attr.target field, I don't think it's right. As gfc_component structs belong to the type's gfc_symbol, they are shared between non-pointer and pointer variants. (In reply to comment #26) (In reply to comment #24) Or maybe drop restrict all together on the type for correctness. Indeed when we introduced the restrict handling to the Fortran frontend we thought that the above case would not happen, thus that the testcase in question would be not a valid Fortran program. At the moment we probably even could generate a testcase that generates wrong-code (when the ICE silences itself with release-checking). This means that simply trying to make it not ICE is probably wrong and simply hides the real issue (which the ICE shows). It is, btw, a sign of bad Fortran language design and makes the point of the pointer/target attributes moot. I think it makes some sense: If there is more than one data path to a struct, there is more than one data path to all of its components. Thus the inherited target attribute. It's just it doesn't fit the C-minded middle-end well. :-( What we could do is drop restrict qualifications for all aggregate types. At least such funny games do not seem possible with mere toplevel arrays or scalars, right? Well, i think so. By the way, does the middle-end support creating a variant of a type with a sub-component restrict (un)qualified ? No. For type variants all the fields are usually shared, you'd have to create a deep copy. Which means they are not type-compatible anymore ? Which means casts everywhere ?
[Bug target/47318] _mm256_maskstore_pd has wrong prototype
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47318 --- Comment #3 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2011-01-17 13:10:22 UTC --- Author: hjl Date: Mon Jan 17 13:10:18 2011 New Revision: 168900 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168900 Log: Correct mask operand for AVX mask load/store. gcc/ 2011-01-17 H.J. Lu hongjiu...@intel.com Backport from mainline 2011-01-17 H.J. Lu hongjiu...@intel.com PR target/47318 * config/i386/avxintrin.h (_mm_maskload_pd): Change mask to __m128i. (_mm_maskstore_pd): Likewise. (_mm_maskload_ps): Likewise. (_mm_maskstore_ps): Likewise. (_mm256_maskload_pd): Change mask to __m256i. (_mm256_maskstore_pd): Likewise. (_mm256_maskload_ps): Likewise. (_mm256_maskstore_ps): Likewise. * config/i386/i386-builtin-types.def: Updated. (ix86_expand_special_args_builtin): Likewise. * config/i386/i386.c (bdesc_special_args): Update __builtin_ia32_maskloadpd, __builtin_ia32_maskloadps, __builtin_ia32_maskloadpd256, __builtin_ia32_maskloadps256, __builtin_ia32_maskstorepd, __builtin_ia32_maskstoreps, __builtin_ia32_maskstorepd256 and __builtin_ia32_maskstoreps256. * config/i386/sse.md (avx_maskloadssemodesuffixavxmodesuffix): Use avxpermvecmode on mask register. (avx_maskstoressemodesuffixavxmodesuffix): Likewise. gcc/testsuite/ 2011-01-17 H.J. Lu hongjiu...@intel.com Backport from mainline 2011-01-17 H.J. Lu hongjiu...@intel.com PR target/47318 * gcc.target/i386/avx-vmaskmovpd-1.c: New. * gcc.target/i386/avx-vmaskmovpd-2.c: Likewise. * gcc.target/i386/avx-vmaskmovps-1.c: Likewise. * gcc.target/i386/avx-vmaskmovps-1.c: Likewise. * gcc.target/i386/avx-vmaskmovpd-256-1.c (avx_test): Load mask as __m256i. * gcc.target/i386/avx-vmaskmovpd-256-2.c (avx_test): Likewise. * gcc.target/i386/avx-vmaskmovps-256-1.c (avx_test): Likewise. * gcc.target/i386/avx-vmaskmovps-256-2.c (avx_test): Likewise. Added: branches/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/avx-vmaskmovpd-1.c branches/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/avx-vmaskmovpd-2.c branches/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/avx-vmaskmovps-1.c branches/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/avx-vmaskmovps-2.c Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/config/i386/avxintrin.h branches/gcc-4_5-branch/gcc/config/i386/i386-builtin-types.def branches/gcc-4_5-branch/gcc/config/i386/i386.c branches/gcc-4_5-branch/gcc/config/i386/sse.md branches/gcc-4_5-branch/gcc/testsuite/ChangeLog branches/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/avx-vmaskmovpd-256-1.c branches/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/avx-vmaskmovpd-256-2.c branches/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/avx-vmaskmovps-256-1.c branches/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/avx-vmaskmovps-256-2.c
[Bug fortran/45586] [4.6 Regression] ICE non-trivial conversion at assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 --- Comment #28 from Tobias Burnus burnus at gcc dot gnu.org 2011-01-17 13:20:42 UTC --- (In reply to comment #26) It is, btw, a sign of bad Fortran language design and makes the point of the pointer/target attributes moot. Well, I think it is just different model, which is used by the middle end and by the Fortran language, thus there is no simple one-to-one matching. That a hack was needed to get a better restricted support is already a hint that the models are a bit incompatible. Fortran's handling is simple: Every variable does not alias by default - the compiler only has to assume aliasing (of the variable and its components) if the variable is explicitly marked as TARGET in that scope; for sections of code where it does not have a TARGET attribute, the user has to ensure that there is no aliasing. There is only one complication: pointers and pointer components of derived types (TYPE) can alias. [Cf. comment 18] Seemingly there is an issue of propagating this information properly to the middle end. Thus, for the first test case (comment 1): TYPE realspace_grid_type REAL(KIND=dp), DIMENSION ( :, :, : ), ALLOCATABLE :: r END TYPE realspace_grid_type TYPE(realspace_grid_type), POINTER :: x, y The POINTER attribute means that x and y are pointers; thus, if x and y are the same, x%r and y%r are the same, if x and y are different, x%r and y%r are different arrays. Additionally, the pointer attribute means that x%r and y%r have implicitly the TARGET attribute. Quoting comment 15: You then need to make sure to create variant types of aggregates with the target attribute applied to all subtypes (thus, the restrict stuff removed) as the middle-end doesn't know about this rule. Which seems to be sensible - though it might need a substantial rework of the FE to keep all the time both variants available: From comment 24: Note that the data member has lost the restrict too. Thus, when creating such pointer qualified types, one should take care not to update the sym-backend_decl of the derived type as they are different. That looks like a substantial rework. One way would be to keep for data types all the time the two versions around: One with restrict and one without restrict; thus, if one does type extension, one has always a fully restrictless data type. Unfortunately, that seems to cause a missed-optimization for type t integer :: a integer, pointer :: b end type t type(t) :: x as x%a cannot alias and only x%b can - but is seems that one cannot encode this for the ME such that t as a whole has to be marked as unrestricted. Or maybe drop restrict all together on the type for correctness. Well, restrict is a very important means to allow for optimization; at least as long as no POINTER is involved (neither the data type nor a component) and also no TARGET, one should really use restricted pointers. For the other cases, one has probably to accept that the ME does not support Fortran's rules :-( I think the easiest would be to create for derived types sym-backend_decl and another backend_decl with restrict - and propagate both variants types through, when extending the type or including it into another type. As soon as it is used as POINTER component, one could drop propagating the backend_decl_restricted.
[Bug target/47312] [4.6 Regression] ICE: in expand_ternary_op, at optabs.c:656 with -flto -mno-sse -mxop and __builtin_fmaf()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47312 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.01.17 13:29:34 Target Milestone|--- |4.6.0 Ever Confirmed|0 |1
[Bug lto/47287] FAIL: gcc.c-torture/execute/builtins/20010124-1.c execution with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47287 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011.01.17 13:42:08 Ever Confirmed|0 |1 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-17 13:42:08 UTC --- (In reply to comment #2) dave@gsyprf11:~/gcc-4.6/objdir/gcc/testsuite/gcc$ less 20010124-1.res 3 20010124-1.o 3 70 e5ddcfb3 PREEMPTED_IR main_test 76 e5ddcfb3 PREEMPTED_IR g 101 e5ddcfb3 PREEMPTED_IR f 20010124-1-lib.o 3 104 af7ae83d PREVAILING_DEF_IRONLY f 118 af7ae83d PREVAILING_DEF_IRONLY g 144 af7ae83d PREEMPTED_IR inside_main main.o 3 70 bb83b83f PREVAILING_DEF main 76 bb83b83f PREVAILING_DEF_IRONLY main_test 79 bb83b83f PREVAILING_DEF_IRONLY inside_main Hum - it has found a definition of main_test in main.o(!?). Can't see such in its source. It also misses 20010124-1.c memcpy PREVAILING_DEF[_IRONLY]. Maybe that one shifts into the other unit as a new function? Weird. I suppose you are using GNU ld, right? On trunk x86_64 with stock binutils 2.21 I get cat 20010124-1.res 3 20010124-1.o 3 79 2651d4ed PREVAILING_DEF_IRONLY main_test 85 2651d4ed RESOLVED_IR g 110 2651d4ed RESOLVED_IR f 20010124-1-lib.o 3 113 f6a75653 PREVAILING_DEF_IRONLY f 127 f6a75653 PREVAILING_DEF_IRONLY g 153 f6a75653 RESOLVED_IR inside_main main.o 3 79 2cccb08f PREVAILING_DEF main 85 2cccb08f RESOLVED_IR main_test 88 2cccb08f PREVAILING_DEF_IRONLY inside_main thus, memcpy is also missing but at least main_test is correctly used from 20010124-1.o. Thus - can you tell us your exact GNU ld version and maybe debug what is the lto_symtab contents we generate (there is a lto-plugin/lto-symtab.c program, not sure if it still works ...)
[Bug target/47219] ICE mems_in_disjoint_alias_sets_p, at alias.c:401
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47219 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED URL||http://gcc.gnu.org/ml/gcc-p ||atches/2011-01/msg00916.htm ||l Component|go |target Resolution||FIXED Target Milestone|--- |4.6.0 --- Comment #4 from Rainer Orth ro at gcc dot gnu.org 2011-01-17 13:45:51 UTC --- Fixed for 4.6.0.
[Bug lto/47274] [4.6 regression] ICE in lto_varpool_replace_node, at lto-symtab.c:306
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47274 --- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-17 13:49:47 UTC --- I can't reproduce this with the testcase from comment #3 on x86_64-linux with either gold or GNU ld from stock binutils 2.21 nor without using the linker plugin. The only call to lto_varpool_replace_node sees Breakpoint 5, lto_varpool_replace_node (vnode=0x75d041a0, prevailing_node=0x75d040d0) at /space/rguenther/src/svn/trunk/gcc/lto-symtab.c:304 304 if (vnode-needed) (gdb) n 306 gcc_assert (!vnode-analyzed || prevailing_node-analyzed); (gdb) p vnode-analyzed $1 = 0 (gdb) p prevailing_node-analyzed $2 = 1 Note that the assert probably should do , not ||. Or it doesn't make sense at all. Asserting that the prevailing_node is analyzed should be enough. Honza? People, you have to show us what goes wrong for you.
[Bug fortran/45586] [4.6 Regression] ICE non-trivial conversion at assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 --- Comment #29 from Michael Matz matz at gcc dot gnu.org 2011-01-17 13:52:20 UTC --- It is, btw, a sign of bad Fortran language design I don't see that. The frontend merely needs to emit correctly typed expressions. And that the type of 'a%b%ptr%d' depends on the prefix 'a%b%ptr' is no wonder and happens with most languages. and makes the point of the pointer/target attributes moot. Not really. The point being that non-pointer objects themself can't refer to any other object, and that non-target objects can't be referred to by anything else than their name or dummies. So, as long as no pointer is involved in an expression all is well. And as soon as a pointer is involved everything works automatically iff the pointer variable has the correct type (namely a type with an implied target attribute everywhere, which in frontend parlance is equivalent to a type without any restrict markers applied). What we could do is drop restrict qualifications for all aggregate types. At least such funny games do not seem possible with mere toplevel arrays or scalars, right? IIRC the spec2k6 cases for which I added the restrict support were using aggregate types :-/
[Bug boehm-gc/47309] gcc-4.4.5 fails to build on darwin/ppc due to issues in boehm-gc GC_test_and_set
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47309 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target||powerpc-apple-darwin9 Status|UNCONFIRMED |WAITING Last reconfirmed||2011.01.17 13:53:07 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-17 13:53:07 UTC --- How did you configure GCC? It seems you are building without bootstrap and/or with custom CFLAGS (you lack any optimization).
[Bug target/47318] _mm256_maskstore_pd has wrong prototype
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47318 --- Comment #4 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2011-01-17 13:54:46 UTC --- Author: hjl Date: Mon Jan 17 13:54:43 2011 New Revision: 168904 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168904 Log: Correct mask operand for AVX mask load/store. gcc/ 2011-01-17 H.J. Lu hongjiu...@intel.com Backport from mainline 2011-01-17 H.J. Lu hongjiu...@intel.com PR target/47318 * config/i386/avxintrin.h (_mm_maskload_pd): Change mask to __m128i. (_mm_maskstore_pd): Likewise. (_mm_maskload_ps): Likewise. (_mm_maskstore_ps): Likewise. (_mm256_maskload_pd): Change mask to __m256i. (_mm256_maskstore_pd): Likewise. (_mm256_maskload_ps): Likewise. (_mm256_maskstore_ps): Likewise. * config/i386/i386-builtin-types.def: Updated. (ix86_expand_special_args_builtin): Likewise. * config/i386/i386.c (ix86_special_builtin_type): Remove V8SF_FTYPE_PCV8SF_V8SF, V4DF_FTYPE_PCV4DF_V4DF, V4SF_FTYPE_PCV4SF_V4SF, V2DF_FTYPE_PCV2DF_V2DF, VOID_FTYPE_PV8SF_V8SF_V8SF, VOID_FTYPE_PV4DF_V4DF_V4DF, VOID_FTYPE_PV4SF_V4SF_V4SF and VOID_FTYPE_PV2DF_V2DF_V2DF. Add V8SF_FTYPE_PCV8SF_V8SI, V4DF_FTYPE_PCV4DF_V4DI, V4SF_FTYPE_PCV4SF_V4SI, V2DF_FTYPE_PCV2DF_V2DI, VOID_FTYPE_PV8SF_V8SI_V8SF, VOID_FTYPE_PV4DF_V4DI_V4DF, VOID_FTYPE_PV4SF_V4SI_V4SF and VOID_FTYPE_PV2DF_V2DI_V2DF. (bdesc_special_args): Update __builtin_ia32_maskloadpd, __builtin_ia32_maskloadps, __builtin_ia32_maskloadpd256, __builtin_ia32_maskloadps256, __builtin_ia32_maskstorepd, __builtin_ia32_maskstoreps, __builtin_ia32_maskstorepd256 and __builtin_ia32_maskstoreps256. (ix86_init_mmx_sse_builtins): Updated. * config/i386/sse.md (avx_maskloadssemodesuffixavxmodesuffix): Use avxpermvecmode on mask register. (avx_maskstoressemodesuffixavxmodesuffix): Likewise. gcc/testsuite/ 2011-01-17 H.J. Lu hongjiu...@intel.com Backport from mainline 2011-01-17 H.J. Lu hongjiu...@intel.com PR target/47318 * gcc.target/i386/avx-vmaskmovpd-1.c: New. * gcc.target/i386/avx-vmaskmovpd-2.c: Likewise. * gcc.target/i386/avx-vmaskmovps-1.c: Likewise. * gcc.target/i386/avx-vmaskmovps-1.c: Likewise. * gcc.target/i386/avx-vmaskmovpd-256-1.c (avx_test): Load mask as __m256i. * gcc.target/i386/avx-vmaskmovpd-256-2.c (avx_test): Likewise. * gcc.target/i386/avx-vmaskmovps-256-1.c (avx_test): Likewise. * gcc.target/i386/avx-vmaskmovps-256-2.c (avx_test): Likewise. Added: branches/gcc-4_4-branch/gcc/testsuite/gcc.target/i386/avx-vmaskmovpd-1.c branches/gcc-4_4-branch/gcc/testsuite/gcc.target/i386/avx-vmaskmovpd-2.c branches/gcc-4_4-branch/gcc/testsuite/gcc.target/i386/avx-vmaskmovps-1.c branches/gcc-4_4-branch/gcc/testsuite/gcc.target/i386/avx-vmaskmovps-2.c Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/config/i386/avxintrin.h branches/gcc-4_4-branch/gcc/config/i386/i386.c branches/gcc-4_4-branch/gcc/config/i386/sse.md branches/gcc-4_4-branch/gcc/testsuite/ChangeLog branches/gcc-4_4-branch/gcc/testsuite/gcc.target/i386/avx-vmaskmovpd-256-1.c branches/gcc-4_4-branch/gcc/testsuite/gcc.target/i386/avx-vmaskmovpd-256-2.c branches/gcc-4_4-branch/gcc/testsuite/gcc.target/i386/avx-vmaskmovps-256-1.c branches/gcc-4_4-branch/gcc/testsuite/gcc.target/i386/avx-vmaskmovps-256-2.c
[Bug preprocessor/47328] New: preprocessor handles backslash at the end of a line incorrectly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47328
Summary: preprocessor handles backslash at the end of a line
incorrectly
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gccbugzi...@trash-mail.com
I use the gcc preprocessor to process structures like
@ define vunpack_uchar4(OUT,IN) { \
uint _in = (uint)(IN); \
OUT.x = (_in 0) 0xFF; \
OUT.y = (_in 8) 0xFF; \
OUT.z = (_in 16) 0xFF; \
OUT.w = (_in 24) 0xFF; \
}
(the @ is not a typo but intended. this should not be handled like macro
definition)
The backslash at the end of the line was handled correctly up to gcc 4.5.0. Now
the backslash is removed, but the lines are _not_ concatenated.
[Bug web/47306] Wrong name of a programming language used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47306 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.01.17 14:14:48 CC||iant at google dot com Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-17 14:14:48 UTC --- Confirmed.
[Bug preprocessor/47328] preprocessor handles backslash at the end of a line incorrectly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47328 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-17 14:18:56 UTC --- . *** This bug has been marked as a duplicate of bug 45696 ***
[Bug preprocessor/45696] Continuation character gets lost or not taken into account
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45696 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added CC||gccbugzi...@trash-mail.com --- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-17 14:18:56 UTC --- *** Bug 47328 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/45934] [4.6 Regression] g++.old-deja/g++.other/dtor5.C FAILs with -finline-small-functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45934 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #12 from Martin Jambor jamborm at gcc dot gnu.org 2011-01-17 14:45:13 UTC --- It is.
[Bug tree-optimization/46302] [4.6 Regression] Program with virtual public inheritance crashes at O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46302 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #10 from Martin Jambor jamborm at gcc dot gnu.org 2011-01-17 14:45:49 UTC --- Fixed.
[Bug middle-end/47313] [4.6 Regression] ICE: PHI argument is not a GIMPLE value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47313 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-17 14:48:47 UTC --- Fixed.
[Bug middle-end/47313] [4.6 Regression] ICE: PHI argument is not a GIMPLE value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47313 --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-17 14:48:38 UTC --- Author: rguenth Date: Mon Jan 17 14:48:35 2011 New Revision: 168907 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168907 Log: 2011-01-17 Richard Guenther rguent...@suse.de PR tree-optimization/47313 * tree-inline.c (tree_function_versioning): Move DECL_RESULT handling before copying the body. Properly deal with by-reference result in SSA form. * g++.dg/torture/pr47313.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/torture/pr47313.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-inline.c
[Bug tree-optimization/47290] [4.5/4.6 Regression] memory exhausted compiling a destructor with an infinite 'for (;;);' loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47290 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-17 14:49:53 UTC --- Created attachment 22995 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22995 gcc46-pr47290.patch Ugh, cddce pass for empty loop: L0: bb 6: goto bb 6; creates a preheader: L0: bb 6: bb 7: goto bb 6; so suddenly we have an empty infinite loop containing two bbs instead of one, on which cleanup_empty_eh keeps up oscillating between the landing pads on bb 6 and on bb 7 forever. There is a check already for empty infinite loops, but it covers just those containing just single bb, not more than that. I wonder if ehcleanup should be prepared for empty infinite loops containing arbitrary number of bbs, or if worst case two of them should be possible (that can be fixed by the attached patch) and why a preheader is created inside of the loop instead of before it.
[Bug lto/47287] FAIL: gcc.c-torture/execute/builtins/20010124-1.c execution with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47287 --- Comment #4 from dave at hiauly1 dot hia.nrc.ca 2011-01-17 15:12:38 UTC --- I suppose you are using GNU ld, right? Yes (gold has not been ported). On trunk x86_64 with stock binutils 2.21 I get cat 20010124-1.res 3 20010124-1.o 3 79 2651d4ed PREVAILING_DEF_IRONLY main_test 85 2651d4ed RESOLVED_IR g 110 2651d4ed RESOLVED_IR f 20010124-1-lib.o 3 113 f6a75653 PREVAILING_DEF_IRONLY f 127 f6a75653 PREVAILING_DEF_IRONLY g 153 f6a75653 RESOLVED_IR inside_main main.o 3 79 2cccb08f PREVAILING_DEF main 85 2cccb08f RESOLVED_IR main_test 88 2cccb08f PREVAILING_DEF_IRONLY inside_main thus, memcpy is also missing but at least main_test is correctly used from 20010124-1.o. Thus - can you tell us your exact GNU ld version and maybe debug what is the lto_symtab contents we generate (there is a lto-plugin/lto-symtab.c program, not sure if it still works ...) It has been rebuilt a number of times recently. Last night's test run still shows the bug and it used: dave@gsyprf11:~/gcc-4.6/objdir$ ld --version GNU ld (GNU Binutils) 2.21.51.20110116 I tried to do a build without plugin support, but it seems there is a ld configure bug and plugin support can't be disabled. With older versions, I think plugin support had to be explicitly enabled (default was no). I'll try to debug the lto_symtab contents tonight. Dave
[Bug tree-optimization/47290] [4.5/4.6 Regression] memory exhausted compiling a destructor with an infinite 'for (;;);' loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47290 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-17 15:21:36 UTC --- Small correction, the empty infinite loop is not split because of preheader creation, but because of force_single_succ_latches - the condition there causes edge split even when latch has single succ if header and latch are the same: if (loop-latch != loop-header single_succ_p (loop-latch)) continue;
[Bug lto/47274] [4.6 regression] ICE in lto_varpool_replace_node, at lto-symtab.c:306
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47274
--- Comment #7 from John David Anglin danglin at gcc dot gnu.org 2011-01-17
15:42:26 UTC ---
Resolution file is:
3
abs-1.o 3
70 262910e5 PREEMPTED_IR main_test
84 262910e5 PREEMPTED_IR abs
88 262910e5 PREEMPTED_IR abs_called
abs-1-lib.o 3
70 b13b015b PREVAILING_DEF_IRONLY abs
101 b13b015b PREEMPTED_IR inside_main
103 b13b015b PREVAILING_DEF_IRONLY abs_called
main.o 3
70 e5772d37 PREVAILING_DEF main
76 e5772d37 PREVAILING_DEF_IRONLY main_test
79 e5772d37 PREVAILING_DEF_IRONLY inside_main
/tmp/ccJGcG05.lto.o is empty:
dave@gsyprf11:~/gcc-4.6/objdir/gcc/testsuite/gcc$ ls -l /tmp/ccJGcG05.lto.o
-rw--- 1 dave users 0 Jan 17 07:20 /tmp/ccJGcG05.lto.o
Assert fails at this point:
Breakpoint 1, lto_varpool_replace_node (prevailing_node=0x404591c0,
vnode=0x40459150) at ../../gcc/gcc/lto-symtab.c:306
306 gcc_assert (!vnode-analyzed || prevailing_node-analyzed);
(gdb) p vnode-analyzed
$7 = 1
(gdb) p prevailing_node-analyzed
$8 = 0
(gdb) p *vnode
$9 = {decl = 0x4045a480, next = 0x0, prev = 0x404591c0,
next_needed = 0x404591f8, prev_needed = 0x0, extra_name = 0x0,
same_comdat_group = 0x0, ref_list = {references = 0x0, refering = 0xc652e0},
lto_file_data = 0x4045b000, aux = 0x0, order = 3, resolution = LDPR_UNKNOWN,
needed = 1, force_output = 0, analyzed = 1, finalized = 1, output = 0,
externally_visible = 1, alias = 0, used_from_other_partition = 0,
in_other_partition = 0}
(gdb) p *prevailing_node
$10 = {decl = 0x4045a780, next = 0x40459150, prev = 0x404591f8,
next_needed = 0x0, prev_needed = 0x0, extra_name = 0x0,
same_comdat_group = 0x0, ref_list = {references = 0x0, refering = 0xc65be8},
lto_file_data = 0x4045b0a0, aux = 0x0, order = 8,
resolution = LDPR_PREVAILING_DEF_IRONLY, needed = 1, force_output = 0,
analyzed = 0, finalized = 0, output = 0, externally_visible = 0, alias = 0,
used_from_other_partition = 0, in_other_partition = 0}
(gdb) p debug_tree (vnode-decl)
var_decl 0x4045a480 abs_called
type integer_type 0x403fc2a0 int public SI
size integer_cst 0x403f1270 constant 32
unit size integer_cst 0x403f10a8 constant 4
align 32 symtab 0 alias set -1 structural equality precision 32 min
integer_cst 0x403f1228 -2147483648 max integer_cst 0x403f1240 2147483647
pointer_to_this pointer_type 0x403fcb40
used public static SI file
/home2/dave/gcc-4.6/gcc/gcc/testsuite/gcc.c-torture/execute/builtins/abs-1.c
line 7 col 5 size integer_cst 0x403f1270 32 unit size integer_cst 0x403f10a8
4
align 32 context translation_unit_decl 0x40404700 D.1190 initial
integer_cst 0x403f1528 0
(mem/c/i:SI (symbol_ref:SI (abs_called) [flags 0x2] var_decl 0x4045a480
abs_called) [0 abs_called+0 S4 A32])
$11 = void
(gdb) p debug_tree (prevailing_node-decl)
var_decl 0x4045a780 abs_called
type integer_type 0x403fc2a0 int public SI
size integer_cst 0x403f1270 constant 32
unit size integer_cst 0x403f10a8 constant 4
align 32 symtab 0 alias set -1 structural equality precision 32 min
integer_cst 0x403f1228 -2147483648 max integer_cst 0x403f1240 2147483647
pointer_to_this pointer_type 0x403fcb40
used public external common SI file
/home2/dave/gcc-4.6/gcc/gcc/testsuite/gcc.c-torture/execute/builtins/abs-1-lib.c
line 2 col 12 size integer_cst 0x403f1270 32 unit size integer_cst
0x403f10a8 4
align 32 context translation_unit_decl 0x40404770 D.1196
$12 = void
[Bug target/47312] [4.6 Regression] ICE: in expand_ternary_op, at optabs.c:656 with -flto -mno-sse -mxop and __builtin_fmaf()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47312 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-17 15:46:52 UTC --- With LTO, relying on FMA_EXPR being present in the IL only iff target supports it is IMHO wrong, because using slightly different options between cc1 and lto1 can result in optab_handler (fma_optab, mode) == CODE_FOR_nothing even when FMA_EXPR is present in the IL. I'd say we should expand FMA_EXPR as __builtin_fma in that case. Richi, do you agree?
[Bug c++/47326] ICE in tsubst_copy (triggered by dependency of return type on parameter pack size)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47326 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011.01.17 15:49:07 Ever Confirmed|0 |1 --- Comment #2 from H.J. Lu hjl.tools at gmail dot com 2011-01-17 15:49:07 UTC --- Where is the attached file?
[Bug c++/47329] New: cc1plus segfaults when using variadic function template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47329
Summary: cc1plus segfaults when using variadic function
template
Product: gcc
Version: 4.4.5
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gmai...@gmail.com
g++ reports segfault in cc1plus when attempting to compile code sample provided
below:
$ g++ -std=c++0x -o test test.cpp
g++: Internal error: Segmentation fault (program cc1plus)
Please submit a full bug report.
See file:///usr/share/doc/gcc-4.4/README.Bugs for instructions.
$ g++ --version
g++ (Ubuntu/Linaro 4.4.4-14ubuntu5) 4.4.5
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
-- test.cpp ---
# include iostream
# include vector
void print(const std::vectorint pack)
{
for(size_t i=0; ipack.size(); i++)
std::cout pack[i] ;
std::cout \n;
}
templatetypename ...Vals
void print(std::vectorint pack, int v1, Vals... vals)
{
pack.push_back(v1);
print(pack, vals...);
}
templatetypename ...Vals
void print(Vals... vals)
{
std::vectorint pack;
print(pack, vals...);
}
int main()
{
print(1);
print(a); // -- this line triggers the failure
print(2, 3, 4, 5);
print(6, 7);
}
[Bug tree-optimization/47179] [4.5/4.6 Regression] SPU: errno misoptimization around malloc call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47179 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 CC||jakub at gcc dot gnu.org
[Bug driver/47330] New: libdecnumber/Makefile.in overrides CFLAGS set by sub make invocation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47330 Summary: libdecnumber/Makefile.in overrides CFLAGS set by sub make invocation Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver AssignedTo: unassig...@gcc.gnu.org ReportedBy: r...@us.ibm.com Apologies for not selecting the appropriate component, but there isn't one for libdecnumber. libdecnumber is pulled into libdfp as well as used in libgcc. Due to lack of flexibility in autoconf, sub-invocations of configure only pass the original CFLAGS from the parent configure to a sub invocation configure. i.e. only those CFLAGS used to configure libdfp are passed to libdecnumber/configure. This means that if libdfp/configure updates CFLAGS this update is only implicitly used in libdfp/configure and libdfp/Makefile. Due to how libdecnumber/Makefile.in has defined CFLAGS the CFLAGS updated in libdfp/Makefile will not normally propagate to libdecnumber/Makefile: CFLAGS = @CFLAGS@ That is, unless the entire environment is passed in the libdecnumber/Makefile invocation. But doing this is a bad idea since it may pollute the makefile namespace with outside variables (we've seen bugs from this). Currently libdfp/Makefile invokes a submake in libdecnumber/Makefile with the following: DEFS=-D__STDC_DEC_FP__=200704L $(mzarch) CFLAGS=$(CFLAGS) $(MAKE) -C $(dfp_backend) Due to how CFLAGS are set, libdecnumber/Makefile.in ($(dfp_backend) in this case) ignores the passed in CFLAGS and uses the CFLAGS that were set during libdecnumber/configure. This means that if libdfp modified CFLAGS they won't get passed to libdecnumber. One place this has come up is when setting fPIC. We'd like to append fPIC to CFLAGS but currently we have to do the following to get libdecnumber to use it: DEFS=-D__STDC_DEC_FP__=200704L $(mzarch) -fPIC $(MAKE) -C $(dfp_backend) We obviously want CFLAGS congruent between libdfp/Makefile and libdecnumber/Makefile to avoid confusion and bugs. This can all be solved by making the following change in libdecnumber/Makefile.in: CFLAGS ?= @CFLAGS@ This means: use the CFLAGS passed in from libdecnumber/configure if no other CFLAGS were passed in during libdecnumber/Makefile invocation. This should continue to work as-is with GCC and will allow Libdfp to have congruent CFLAGS with libdecnumber. Thanks
[Bug preprocessor/47311] [4.6 Regression][C++0x] ICE in tsubst @cp/pt.c:10502
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47311 --- Comment #15 from Richard Henderson rth at gcc dot gnu.org 2011-01-17 16:03:09 UTC --- (In reply to comment #10) But it never checks the buffer end. It looks bogus to me. Read the comment at the beginning of the section. This is an aligned read before END, and thus will never fault. We are guaranteed to find an end-of-line character at the end of the buffer, so we will never search past END.
[Bug lto/47274] [4.6 regression] ICE in lto_varpool_replace_node, at lto-symtab.c:306
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47274 --- Comment #8 from Jan Hubicka hubicka at ucw dot cz 2011-01-17 16:03:37 UTC --- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47274 --- Comment #7 from John David Anglin danglin at gcc dot gnu.org 2011-01-17 15:42:26 UTC --- Resolution file is: 3 abs-1.o 3 70 262910e5 PREEMPTED_IR main_test 84 262910e5 PREEMPTED_IR abs 88 262910e5 PREEMPTED_IR abs_called abs-1-lib.o 3 70 b13b015b PREVAILING_DEF_IRONLY abs 101 b13b015b PREEMPTED_IR inside_main 103 b13b015b PREVAILING_DEF_IRONLY abs_called main.o 3 70 e5772d37 PREVAILING_DEF main 76 e5772d37 PREVAILING_DEF_IRONLY main_test 79 e5772d37 PREVAILING_DEF_IRONLY inside_main /tmp/ccJGcG05.lto.o is empty: dave@gsyprf11:~/gcc-4.6/objdir/gcc/testsuite/gcc$ ls -l /tmp/ccJGcG05.lto.o -rw--- 1 dave users 0 Jan 17 07:20 /tmp/ccJGcG05.lto.o Assert fails at this point: Breakpoint 1, lto_varpool_replace_node (prevailing_node=0x404591c0, vnode=0x40459150) at ../../gcc/gcc/lto-symtab.c:306 306 gcc_assert (!vnode-analyzed || prevailing_node-analyzed); (gdb) p vnode-analyzed $7 = 1 (gdb) p prevailing_node-analyzed $8 = 0 We need to debug how the defined node ends up to be unanalyzed. I assume it is abs_called variable? It seems that we get wrong already when streaming abs-1-lib.o file. Would be possible to attach cgraph dump from WPA? Honza
[Bug rtl-optimization/37273] [4.4/4.5/4.6 Regression] IRA does not re-materializes addresses (loads from the TOC)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37273 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot |law at redhat dot com |gnu.org | --- Comment #6 from Jeffrey A. Law law at redhat dot com 2011-01-17 16:05:40 UTC --- Some sniff testing on x86 shows that fixing this also helps x86, so I'll be doing more rigorous benchmarking.
[Bug lto/47274] [4.6 regression] ICE in lto_varpool_replace_node, at lto-symtab.c:306
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47274 --- Comment #9 from Jan Hubicka hubicka at ucw dot cz 2011-01-17 16:05:56 UTC --- Note that the assert probably should do , not ||. Or it doesn't make sense at all. Asserting that the prevailing_node is analyzed should be enough. No, the assert basically test that when node is analyzed prevailing_node must be analyzed, too. So the test tests the implication, not conjunction. It is possible that we merge two unanalyzed nodes (such as aliases). Honza
[Bug lto/47287] FAIL: gcc.c-torture/execute/builtins/20010124-1.c execution with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47287 --- Comment #5 from Jan Hubicka hubicka at ucw dot cz 2011-01-17 16:08:05 UTC --- thus, memcpy is also missing but at least main_test is correctly used from 20010124-1.o. memcpy is missing due to hack eliminating all builtins from being output. We discussed this few times. Honza
[Bug lto/47287] FAIL: gcc.c-torture/execute/builtins/20010124-1.c execution with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47287 --- Comment #6 from Jan Hubicka hubicka at gcc dot gnu.org 2011-01-17 16:10:54 UTC --- Is hpux an ELF target? GNU LD plugin implementation contains some hackery to chose proper PREEMPTED/RESOLVED/etc values. Perhaps it is broken on non-elfs. In any case I will prepare patch to turn those aborts into fatal errors with some informative info. We shold not ICE (at least at every occasion) when we are fed with wrong resolution table.
[Bug c/47330] libdecnumber/Makefile.in overrides CFLAGS set by sub make invocation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47330 --- Comment #1 from Andreas Schwab sch...@linux-m68k.org 2011-01-17 16:13:37 UTC --- You are not supposed to override CFLAGS in sub-makes.
[Bug fortran/47331] New: ICE in make_decl_rtl, at varasm.c:1133
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47331 Summary: ICE in make_decl_rtl, at varasm.c:1133 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: f...@earthlink.net Created attachment 22996 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22996 reproducer Compiling the attached test case with: gfortran-4.6-010811 -ffixed-form -cpp -ffixed-line-length-132 -fopenmp -c -o test-ice.o test-ice.f results in: test-ice.f: In function ‘wrt’: test-ice.f:34:0: internal compiler error: in make_decl_rtl, at varasm.c:1133 Please submit a full bug report, Note that -fopenmp is required. I have not yet had time to try the latest snapshot, and do not currently build trunk directly from svn. This was found using the 08-Jan-2011 snapshot built with: gfortran-4.6-010811 -v Using built-in specs. COLLECT_GCC=gfortran-4.6-010811 COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.6-20110108/configure --prefix=/usr/local --libdir=/usr/local/lib64 --program-suffix=-4.6-010811 --with-arch=corei7 --enable-languages=c,c++,fortran --enable-gold --enable-version-specific-runtime-libs --enable-checking=release --with-system-zlib --enable-linux-futex --without-system-libunwind --with-ppl=/usr/lib64 --with-cloog=/usr/lib64 --enable-lto Thread model: posix gcc version 4.6.0 20110108 (experimental) (GCC)
[Bug lto/47274] [4.6 regression] ICE in lto_varpool_replace_node, at lto-symtab.c:306
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47274 --- Comment #10 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-17 16:14:21 UTC --- The GNU linker made extern int abs_called; prevailing (it's a common, probably works with -fno-common?) instead of int abs_called = 0; thus I think this is a bug in the GNU linker (we remove the zero initializer I think, so maybe out LTO symtab we create is slightly odd).
[Bug lto/47274] [4.6 regression] ICE in lto_varpool_replace_node, at lto-symtab.c:306
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47274 --- Comment #11 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-17 16:15:10 UTC --- (In reply to comment #10) The GNU linker made extern int abs_called; prevailing (it's a common, probably works with -fno-common?) instead of int abs_called = 0; thus I think this is a bug in the GNU linker (we remove the zero initializer I think, so maybe out LTO symtab we create is slightly odd). Which means you can also try -fno-zero-initialized-in-bss
[Bug c/47330] libdecnumber/Makefile.in overrides CFLAGS set by sub make invocation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47330 --- Comment #2 from Ryan S. Arnold rsa at us dot ibm.com 2011-01-17 16:16:55 UTC --- (In reply to comment #1) You are not supposed to override CFLAGS in sub-makes. What's the recommended procedure for making sure fPIC/fpic is used properly, once again relying on the one configuring to pass it in as a CFLAG?
[Bug c/47330] libdecnumber/Makefile.in overrides CFLAGS set by sub make invocation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47330 --- Comment #3 from Andreas Schwab sch...@linux-m68k.org 2011-01-17 16:25:25 UTC --- Those who ignore libtool are forced to reimplement it.
[Bug fortran/47331] ICE in make_decl_rtl, at varasm.c:1133
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47331 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.01.17 17:00:22 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-17 17:00:22 UTC --- Confirmed.
[Bug fortran/47331] [4.6 Regression] ICE in make_decl_rtl, at varasm.c:1133 (with -fopenmp)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47331 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code, openmp CC||burnus at gcc dot gnu.org Summary|ICE in make_decl_rtl, at|[4.6 Regression] ICE in |varasm.c:1133 |make_decl_rtl, at ||varasm.c:1133 (with ||-fopenmp) --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2011-01-17 17:02:21 UTC --- I have marked it as 4.6 regression, though it might be no regression and just an effect of release checking that it works with 4.4 and 4.5. The failing assert is make_decl_rtl's /* A weak alias has TREE_PUBLIC set but not the other bits. */ gcc_assert (TREE_CODE (decl) != VAR_DECL || TREE_STATIC (decl) || TREE_PUBLIC (decl) || DECL_EXTERNAL (decl) || DECL_REGISTER (decl)); Reduced code: subroutine DOIT !$OMP PARALLEL !$OMP MASTER call WRT() !!!$OMP END MASTER !$OMP END PARALLEL end subroutine DOIT subroutine WRT() do K=1,5 ICELL = INDEXMAKER(K) end do end subroutine DOIT call DOIT end
[Bug c++/47332] New: g++ compiler should check for empty while or for bodies
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47332 Summary: g++ compiler should check for empty while or for bodies Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: howa...@nitro.med.uc.edu The current Apple FSF g++-4.2 compiler has a check_empty_body() routine in gcc/cp/parser.c which provides warnings of empty bodies in for and while statements of the form... suggest a space before %;% or explicit braces around empty body in %%s% statement This check in the Apple g++-4.2 allowed the erroneous ; in the for statement in dump_eh_tree(), to be detected (PR47319). This error would have been almost impossible to detect without the check_empty_body() routine present in Apple's g++-4.2 and would be a useful addition to FSF gcc.
[Bug c++/47332] g++ compiler should check for empty while or for bodies
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47332 Jack Howarth howarth at nitro dot med.uc.edu changed: What|Removed |Added Severity|normal |enhancement
[Bug fortran/47331] [4.5/4.6 Regression] ICE in make_decl_rtl, at varasm.c:1133 (with -fopenmp)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47331 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||jakub at gcc dot gnu.org AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.5.3 Summary|[4.6 Regression] ICE in |[4.5/4.6 Regression] ICE in |make_decl_rtl, at |make_decl_rtl, at |varasm.c:1133 (with |varasm.c:1133 (with |-fopenmp) |-fopenmp) --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-17 17:40:15 UTC --- In 4.5 it ICEs with -fopenmp -fwhole-file.
[Bug target/42894] [4.5/4.6 Regression] Invalid rtl sharing in Thumb1.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42894 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added CC||law at redhat dot com --- Comment #16 from Jeffrey A. Law law at redhat dot com 2011-01-17 17:41:05 UTC --- I agree with Jakub -- let's keep the set of CONST expressions which can be shared small, well defined and limited to those which make a significant difference in memory usage, code maintainability, etc. I really don't see much to be gained by allowing these more generic forms -- and they run the real risk of causing bugs. Specifically, if we allow the additional shared forms, then the middle end has to be prepared to deal with fairly arbitrary CONST sharing created by the backends. Getting this wrong results in wrong-code, segfaults and all kinds of ugly and hard to diagnose bugs. I guess the simplest way to summarize how I look at this is we need a compelling reason to expand the set of shared CONST nodes. I'd like to see Andrey's patch go in along with some updated documentation on what CONST nodes can be shared.
[Bug rtl-optimization/46603] gcc.dg/vect/slp-multitypes-2.c execution failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46603 --- Comment #3 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-01-17 17:48:41 UTC --- Author: ebotcazou Date: Mon Jan 17 17:48:36 2011 New Revision: 168917 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168917 Log: Backport from mainline 2010-11-22 Eric Botcazou ebotca...@adacore.com * gcc.dg/pr28796-2.c: SKIP on SPARC/Solaris 8. PR rtl-optimization/46603 * gcc.dg/vect/slp-multitypes-2.c: XFAIL execution on SPARC 32-bit. 2010-08-31 Bingfeng Mei b...@broadcom.com * gcc.dg/vect/pr43430-1.c: Requires vect_condition target. Modified: branches/gcc-4_5-branch/gcc/testsuite/ChangeLog branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/pr28796-2.c branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/vect/pr43430-1.c branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/vect/slp-multitypes-2.c
[Bug rtl-optimization/46603] gcc.dg/vect/slp-multitypes-2.c execution failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46603 --- Comment #4 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-01-17 17:49:31 UTC --- Author: ebotcazou Date: Mon Jan 17 17:49:25 2011 New Revision: 168918 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168918 Log: Backport from mainline 2010-11-22 Eric Botcazou ebotca...@adacore.com * gcc.dg/pr28796-2.c: SKIP on SPARC/Solaris 8. PR rtl-optimization/46603 * gcc.dg/vect/slp-multitypes-2.c: XFAIL execution on SPARC 32-bit. Modified: branches/gcc-4_4-branch/gcc/testsuite/ChangeLog branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/pr28796-2.c branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/vect/slp-multitypes-2.c
[Bug fortran/47331] [4.5/4.6 Regression] ICE in make_decl_rtl, at varasm.c:1133 (with -fopenmp)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47331 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-17 17:49:26 UTC --- Created attachment 22997 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22997 gcc46-pr47331.patch Untested fix.
[Bug lto/47333] New: [4.6 regression] g++.dg/lto/20091219 FAILs on Solaris 2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47333 Summary: [4.6 regression] g++.dg/lto/20091219 FAILs on Solaris 2 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: r...@gcc.gnu.org Host: *-*-solaris2.* Target: *-*-solaris2.* Build: *-*-solaris2.* Between 20110107 and 20110114, there occured a new testsuite failure on Solaris 2 (both SPARC and x86, 32 nd 64-bit): FAIL: g++.dg/lto/20091219 cp_lto_20091219_0.o-cp_lto_20091219_0.o link, -O3 -fl to UNRESOLVED: g++.dg/lto/20091219 cp_lto_20091219_0.o-cp_lto_20091219_0.o execute -O3 -flto output is: Undefinedfirst referenced symbol in file _ZL28__gthrw_pthread_mutex_unlockP14_pthread_mutex.2261.2084 /var/tmp//cc8DaqVq.ltrans0.ltrans.o _ZL26__gthrw_pthread_mutex_lockP14_pthread_mutex.2263.2086 /var/tmp//cc8DaqVq.ltrans0.ltrans.o _ZL20__gthrw_pthread_onceP5_oncePFvvE.2091.2067 /var/tmp//cc8DaqVq.ltrans0.ltrans.o ld: fatal: symbol referencing errors. No output written to g++-dg-lto-20091219-01 collect2: ld returned 1 exit status This is a regression from the 4.5 branch.
[Bug lto/47287] FAIL: gcc.c-torture/execute/builtins/20010124-1.c execution with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47287 John David Anglin danglin at gcc dot gnu.org changed: What|Removed |Added Build|hppa2.0w-hp-hpux11.11 |hppa-unknown-linux-gnu --- Comment #7 from John David Anglin danglin at gcc dot gnu.org 2011-01-17 17:50:59 UTC --- The build entry was wrong. hppa-unknown-linux-gnu target is elf and uses standard binutils tools.
[Bug c++/47332] g++ compiler should check for empty while or for bodies
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47332 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution||INVALID --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-17 17:54:23 UTC --- It was removed on purpose, see PR36478 and discussions about it on gcc-patches.
[Bug lto/47334] New: g++.dg/torture/pr31863.C -O2 -flto FAILs without visibility
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47334 Summary: g++.dg/torture/pr31863.C -O2 -flto FAILs without visibility Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: r...@gcc.gnu.org Host: *-*-solaris2.[89], mips-sgi-irix6.5 Target: *-*-solaris2.[89], mips-sgi-irix6.5 Build: *-*-solaris2.[89], mips-sgi-irix6.5 On platforms without visibility support, g++.dg/torture/pr31863.C -O2 -flto FAILs: FAIL: g++.dg/torture/pr31863.C -O2 -flto (test for excess errors) Excess errors: lto1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes] [...] LTO tests using lto.exp prune this message, but here it is not.
[Bug c/47330] libdecnumber/Makefile.in overrides CFLAGS set by sub make invocation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47330 Ryan S. Arnold rsa at us dot ibm.com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #4 from Ryan S. Arnold rsa at us dot ibm.com 2011-01-17 18:00:05 UTC --- libtool is a mighty big stick to fix this one issue. I'll work around it for the time being by passing it in -DEFS. Closing the bugz.
[Bug preprocessor/47311] [4.6 Regression][C++0x] ICE in tsubst @cp/pt.c:10502
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47311
--- Comment #16 from Pawel Sikora pluto at agmk dot net 2011-01-17 18:05:15
UTC ---
(In reply to comment #15)
(In reply to comment #10)
But it never checks the buffer end. It looks bogus to me.
Read the comment at the beginning of the section. This is an aligned
read before END, and thus will never fault. We are guaranteed to find
an end-of-line character at the end of the buffer, so we will never
search past END.
on valgrind-3.6.0 patched with https://bugs.kde.org/show_bug.cgi?id=262995#c3
with its emulated cpu i got an invalid access in search_line_sse42:
$ valgrind --leak-check=no --trace-children=yes g++46 testcase2.cpp
-std=gnu++0x -Wall -c
==5266== Memcheck, a memory error detector
==5266== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==5266== Using Valgrind-3.6.0 and LibVEX; rerun with -h for copyright info
==5266== Command: g++46 testcase2.cpp -std=gnu++0x -Wall -c
==5266==
==5267== Memcheck, a memory error detector
==5267== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==5267== Using Valgrind-3.6.0 and LibVEX; rerun with -h for copyright info
==5267== Command: /opt/gcc46/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/cc1plus
-quiet -D_GNU_SOURCE testcase2.cpp -quiet -dumpbase testcase2.cpp
-mtune=generic -march=core2 -auxbase testcase2 -Wall -std=gnu++0x -o
/home/users/pluto/tmp/cc1d2Wcp.s
==5267==
==5267== Invalid read of size 8
==5267==at 0x11E4E24: search_line_sse42(unsigned char const*, unsigned char
const*) (lex.c:462)
==5267==by 0x11E4F4E: _cpp_clean_line (lex.c:665)
==5267==by 0x11E5957: _cpp_get_fresh_line (lex.c:1884)
==5267==by 0x11E713D: _cpp_lex_direct (lex.c:1949)
==5267==by 0x11E7FF6: _cpp_lex_token (lex.c:1823)
==5267==by 0x11EA6A7: cpp_get_token(cpp_reader*) (macro.c:1240)
==5267==by 0x11EA93F: cpp_get_token_with_location(cpp_reader*, unsigned
int*) (macro.c:1352)
==5267==by 0x6799B2: c_lex_with_flags(tree_node**, unsigned int*, unsigned
char*, int) (c-lex.c:302)
==5267==by 0x57DA7F: cp_lexer_get_preprocessor_token(cp_lexer*, cp_token*)
(parser.c:549)
==5267==by 0x5A571A: c_parse_file() (parser.c:425)
==5267==by 0x67F4E4: c_common_parse_file() (c-opts.c:1071)
==5267==by 0xA07F57: toplev_main(int, char**) (toplev.c:579)
==5267== Address 0x629b7e0 is 112 bytes inside a block of size 114 alloc'd
==5267==at 0x4C25322: realloc (vg_replace_malloc.c:525)
==5267==by 0x120EDAC: xrealloc (xmalloc.c:179)
==5267==by 0x11D975F: _cpp_convert_input (charset.c:1734)
==5267==by 0x11E1AF2: read_file(cpp_reader*, _cpp_file*) (files.c:652)
==5267==by 0x11E2D5A: _cpp_stack_file (files.c:723)
==5267==by 0x11E4690: cpp_read_main_file(cpp_reader*, char const*)
(init.c:570)
==5267==by 0x67EBE6: c_common_post_options(char const**) (c-opts.c:1010)
==5267==by 0xA0732A: toplev_main(int, char**) (toplev.c:1283)
==5267==by 0x5EBDCBC: (below main) (libc-start.c:226)
454│ /* Main loop, processing 16 bytes at a time. By doing the whole loop
455│ in inline assembly, we can make proper use of the flags set. */
456│ __asm ( sub $16, %1\n
457│.balign 16\n
458│ 0: add $16, %1\n
459│%vpcmpestri $0, (%1), %2\n
460│jnc 0b
461│ : =c(index), +r(s)
462├: x(search), a(4), d(16));
(gdb) p/x s
$1 = 0x629b7e0
(gdb) p/x end
$2 = 0x629b7e1
(gdb) p/x search
$4 = {0xa,
0xd,
0x3f,
0x5c,
0x0 repeats 12 times}
[Bug tree-optimization/47283] [4.6 regression] ICE in refs_may_alias_p_1, at tree-ssa-alias.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47283 --- Comment #5 from Martin Jambor jamborm at gcc dot gnu.org 2011-01-17 18:12:53 UTC --- THe ICE happens because refs_may_alias_p_1 gets an ao_ref initialized from a MEM_REF of an ADDR_EXPR of a component_ref. get_ref_base_and_extent then removes the MEM_REF but the base it returns is a COMPONENT_REF which then confuses refs_may_alias_p_1. The reference is fetched from MEM_EXPR (mem) in ao_ref_from_mem. However, it should be noted that mem is (gdb) call debug_rtx (mem) (mem:SI (debug_implicit_ptr:SI D.58673) [0 D.58673.wd+0 S4 A32]) so perhaps some of the callers should ignore debug instructions or debug-whatever-the-above-is? I don't know which one that would be, the backtrace is (I added a few asserts to alias.c to produce it so the line numbers are a bit off): #0 fancy_abort (file=0x8aa5c84 /home/mjambor/gcc/mine/gcc/alias.c, line=276, function=0x8aa62a2 ao_ref_from_mem) at /home/mjambor/gcc/mine/gcc/diagnostic.c:893 #1 0x082e4432 in ao_ref_from_mem (ref=0xbfffe828, mem=0xb5941bac) at /home/mjambor/gcc/mine/gcc/alias.c:276 #2 0x082e4bc8 in rtx_refs_may_alias_p (x=0xb5caf7c8, mem=value optimized out, tbaa_p=0 '\000') at /home/mjambor/gcc/mine/gcc/alias.c:380 #3 0x082e50a3 in write_dependence_p (mem=0xb5941bac, x=0xb5caf7c8, writep=value optimized out) at /home/mjambor/gcc/mine/gcc/alias.c:2598 #4 0x08a003c9 in sched_analyze_1 (deps=value optimized out, x=value optimized out, insn=value optimized out) at /home/mjambor/gcc/mine/gcc/sched-deps.c:2321 #5 0x08a042ac in sched_analyze_insn (deps=value optimized out, x=0xb5da6054, insn=0xb633e678) at /home/mjambor/gcc/mine/gcc/sched-deps.c:2656 #6 0x08a05df3 in deps_analyze_insn (deps=0xbfffeae0, insn=0xb633e678) at /home/mjambor/gcc/mine/gcc/sched-deps.c:3259 #7 0x08a065b3 in sched_analyze (deps=0xbfffeae0, head=0xb633e678, tail=0xb623cc80) at /home/mjambor/gcc/mine/gcc/sched-deps.c:3407 #8 0x08573c3e in compute_block_dependences (bb=value optimized out) at /home/mjambor/gcc/mine/gcc/sched-rgn.c:2725 #9 sched_rgn_compute_dependencies (bb=value optimized out) at /home/mjambor/gcc/mine/gcc/sched-rgn.c:3162 #10 0x08576484 in schedule_region (rgn=value optimized out) at /home/mjambor/gcc/mine/gcc/sched-rgn.c:2937 #11 schedule_insns (rgn=value optimized out) at /home/mjambor/gcc/mine/gcc/sched-rgn.c:3321 #12 0x08576a8e in rest_of_handle_sched2 () at /home/mjambor/gcc/mine/gcc/sched-rgn.c:3542 #13 0x085193b9 in execute_one_pass (pass=0x8cfaa60) at /home/mjambor/gcc/mine/gcc/passes.c:1561
[Bug fortran/47082] [4.6 Regression] [OOP] ICE in gfc_conv_component_ref
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47082 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 CC||jakub at gcc dot gnu.org
[Bug lto/47274] [4.6 regression] ICE in lto_varpool_replace_node, at lto-symtab.c:306
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47274 --- Comment #12 from dave at hiauly1 dot hia.nrc.ca 2011-01-17 18:32:22 UTC --- On Mon, 17 Jan 2011, hubicka at ucw dot cz wrote: It seems that we get wrong already when streaming abs-1-lib.o file. Would be possible to attach cgraph dump from WPA? Is this what you wanted? Dave
[Bug lto/47274] [4.6 regression] ICE in lto_varpool_replace_node, at lto-symtab.c:306
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47274 --- Comment #13 from dave at hiauly1 dot hia.nrc.ca 2011-01-17 18:39:14 UTC --- Last graph.
