http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57300
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Versi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57300
--- Comment #2 from Jakub Jelinek ---
Created attachment 30130
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30130&action=edit
gcc49-pr57300.patch
Untested fix.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57300
Jakub Jelinek changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57301
Steven Bosscher changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19599
Ramana Radhakrishnan changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57300
--- Comment #4 from Jakub Jelinek ---
The alternative could be, if dead_or_set_p is going to be so rare even in the
near future, to just introduce split_dead_or_set_p wrapper around it, which
would do something like:
if (df_note == NULL)
{
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57294
--- Comment #3 from Marek Polacek ---
void baz (void);
int func ();
static void
bar (int a, int foo (void))
{
baz ();
foo ();
}
void
baz (void)
{
bar (0, func);
}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57300
--- Comment #5 from Steven Bosscher ---
(In reply to Jakub Jelinek from comment #4)
> Not sure if it is safe to run df_analyze when the cfg is gone (split5
> pass)
Well, it doesn't crash but it's not correct. Without basic block
pointers on the i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52239
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #20
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57300
--- Comment #6 from Jakub Jelinek ---
Apparently split* passes aren't the only passes that split insns though, so the
patch I've attached is incomplete anyway.
>From quick skimming, it seems split*, dbr, final, combine and pro_and_epilogue
passes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57124
--- Comment #7 from Richard Biener ---
(In reply to Jeffrey A. Law from comment #4)
> Yea, 254.gap is definitely overflowing signed types. I've got changes to
> make the warnings and -fno-strict-overflow work that I'll put through their
> paces t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10634
Paolo Carlini changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|gcc-bugs at g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57300
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15672
Paolo Carlini changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|gcc-bugs at g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52960
Paolo Carlini changed:
What|Removed |Added
CC||igodard at pacbell dot net
--- Comment #1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57300
--- Comment #8 from Jakub Jelinek ---
Created attachment 30131
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30131&action=edit
/tmp/gcc49-pr57300.patch
The split_dead_or_set_p variant patch.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57300
--- Comment #9 from Steven Bosscher ---
(In reply to Jakub Jelinek from comment #6)
> So supposedly
> bool
> split_dead_or_set_p (rtx insn, const_rtx x)
> {
> if (BLOCK_FOR_INSN (insn) == NULL)
> return false; /* If cfg is gone, be conservat
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57300
--- Comment #10 from Jakub Jelinek ---
Re: Eric's question, not easily, because if we implement that define_split as
define_peephole2, then it won't trigger at all, because the next define_split
";; Extend to memory case when source register does
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57300
--- Comment #11 from Jakub Jelinek ---
Re: s390, the condition includes ACCESS_REG_P test, which is for a0/a1 hard
reg, so I think just adding reload_completed test to the splitters wouldn't be
a problem, and if we introduce peephole2_completed, w
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57297
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57293
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
Target|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57286
--- Comment #7 from Marc Glisse ---
Should be fixed by r198964 (sorry, I changed my mind about where to break the
cycle). Could you check that it works now?
Thanks for the report.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52239
--- Comment #21 from Frédéric Buclin ---
(In reply to Tobias Burnus from comment #20)
> Since the update, the Bugzilla favicon is shown,
> before the GCC one was shown:
Fixed.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57300
--- Comment #12 from Jakub Jelinek ---
Created attachment 30132
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30132&action=edit
gcc49-pr57300.patch
We can actually use epilogue_completed, while that is set already a few passes
before peepho
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57290
--- Comment #3 from Richard Biener ---
I'm trying to reproduce it. Can you on your side verify whether dropping
-ftree-loop-linear changes anything with respect to the regression?
Also what does
(6) -Ofast -funroll-loops -fwhole-program
numbers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57300
--- Comment #13 from Richard Biener ---
(In reply to Steven Bosscher from comment #9)
> (In reply to Jakub Jelinek from comment #6)
> > So supposedly
> > bool
> > split_dead_or_set_p (rtx insn, const_rtx x)
> > {
> > if (BLOCK_FOR_INSN (insn) ==
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56548
Ralf Baechle changed:
What|Removed |Added
CC||r...@linux-mips.org
--- Comment #8 from Ra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56548
--- Comment #9 from Mikael Pettersson ---
(In reply to Ralf Baechle from comment #8)
> FWIW, I'm also hitting the same compiler bug with vanilla GCC 4.7.2 and
> 4.8.0 compiling a heavily patched 3.4 kernel with LTO for a mips64-linux
> target.
Pl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17314
Paolo Carlini changed:
What|Removed |Added
CC|gcc-bugs at gcc dot gnu.org|
--- Comment #13 from Paolo Carlin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17314
Paolo Carlini changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #14
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57283
--- Comment #5 from Lin Yi-Li ---
(In reply to Jonathan Wakely from comment #4)
> N.B. you can also do it with a nested std::bind expression and
> std::logical_not
>
> std::bind(std::logical_not(),
> std::bind(std::mem_fn(&cls::value),
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57294
Martin Jambor changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17314
--- Comment #15 from Jason Merrill ---
Yes, that would be an improvement to the diagnostic. But it seems to me that
there's a deeper issue here: I think both testcases should be ill-formed
because C::C can't form a pointer to its A base in order
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56548
--- Comment #10 from Ralf Baechle ---
As I'm hitting this with LTO on a large test case it's non-trivial to extract a
test case but I will try.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57300
--- Comment #14 from Eric Botcazou ---
> I agree that possibly bogus IL is a smoking gun that waits for this kind
> of bugs to appear. If we do not want to pay the price of removing
> notes can we at least have a flag that tells whether the NOTE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17314
--- Comment #16 from Paolo Carlini ---
I see, thanks Jason. Indeed, the behavior of various compilers I have here is
inconsistent about the various variants of the testcase.
Thus for now I'm going to test the diagnostic tweak with the plan of com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57297
--- Comment #3 from gretay at gcc dot gnu.org ---
Thanks a lot for the quick responses! Unfortunately, the frontend patch alone
doesn't fix the problem, as Richard pointed out, but it may be needed for other
reasons. The tree-sra patch fixes the te
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57301
--- Comment #4 from Jakub Jelinek ---
This regressed presumably with r131862 . Anyway, I don't think the rotate
detection improvements should be backported to the release branches, therefore
this will need to be FIXED in 4.9+ only.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57302
Bug ID: 57302
Summary: Should merge zeroing multiple consecutive memory
locations
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57293
Vladimir Makarov changed:
What|Removed |Added
CC||vmakarov at redhat dot com
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57293
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
with-mpfr=/usr/local/gcc-trunk
--with-mpc=/usr/local/gcc-trunk --with-cloog=/usr/local/gcc-trunk
--prefix=/usr/local/gcc-trunk
Thread model: posix
gcc version 4.9.0 20130516 (experimental) [trunk revision 198967] (GCC)
$ gcc-trunk -O0 small.c
$ ./a.out
0
$ gcc-4.6 -O1 small.c
$ ./a.out
0
$ g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57303
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17410
Paolo Carlini changed:
What|Removed |Added
CC|gcc-bugs at gcc dot gnu.org|
Known to fail|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52239
--- Comment #22 from Tobias Burnus ---
(In reply to Frédéric Buclin from comment #21)
> (In reply to Tobias Burnus from comment #20)
> > Since the update, the Bugzilla favicon is shown,
> > before the GCC one was shown:
> Fixed.
Doesn't work here
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52239
--- Comment #23 from Tobias Burnus ---
(In reply to Tobias Burnus from comment #22)
> Doesn't work here:
Scratch that - the one was seemingly in the cache - despite force-reload. It
*is* fixed.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17410
Paolo Carlini changed:
What|Removed |Added
Status|NEW |RESOLVED
Known to work|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57304
Bug ID: 57304
Summary: Revision 198896 segfaults building cpu2000 benchmark
176.gcc
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Pr
|NEW
Last reconfirmed||2013-05-16
Component|c |libitm
Ever confirmed|0 |1
--- Comment #1 from Uroš Bizjak ---
Confirmed with:
gcc version 4.9.0 20130516 (experimental) [trunk revision
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17459
Paolo Carlini changed:
What|Removed |Added
CC|gcc-bugs at gcc dot gnu.org|
--- Comment #4 from Paolo Carlini
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53991
Uroš Bizjak changed:
What|Removed |Added
Component|middle-end |tree-optimization
--- Comment #2 from Uroš
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57297
--- Comment #4 from Martin Jambor ---
So far I have not attempted to reproduce this myself and so do not
quite follow all the previous comments but...
(In reply to Richard Biener from comment #2)
>
> build_ref_for_offset ends up creating a MEM_R
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17459
--- Comment #5 from Manuel López-Ibáñez ---
(In reply to Paolo Carlini from comment #4)
> Manuel can you help me reassessing this? I think we are doing much better.
I get this:
test.cc:3:19: error: invalid use of non-static member function
vo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57303
--- Comment #2 from H.J. Lu ---
It is caused by revision 170984:
http://gcc.gnu.org/ml/gcc-cvs/2011-03/msg00405.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49146
--- Comment #6 from Ben Woodard ---
Created attachment 30134
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30134&action=edit
reproducer program
still working on getting access to the machine where I have ICC. My password
expired.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18126
Paolo Carlini changed:
What|Removed |Added
CC|gcc-bugs at gcc dot gnu.org|
Assignee|unassigned at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49146
Richard Henderson changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57305
Bug ID: 57305
Summary: ICE with warnings and unlimited polymorphic (incorrect
code)
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Pr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57303
--- Comment #3 from H.J. Lu ---
statement_sink_location in
/* A killing definition is not a use. */
if (gimple_assign_single_p (use_stmt)
&& gimple_vdef (use_stmt)
&& operand_equal_p (gimple_assign
lib
--with-gmp=/home/abenson/Galacticus/Tools
Thread model: posix
gcc version 4.9.0 20130516 (experimental) (GCC)
$ gfortran -c bug.F90 -o bug.o
bug.F90:7:0: internal compiler error: in gfc_conv_structure, at
fortran/trans-expr.c:6027
class(c), public, pointer :: cc => cd
^
0x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57305
--- Comment #1 from Vladimir Fuka ---
Created attachment 30136
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30136&action=edit
ice7.f90 (second source)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57305
--- Comment #2 from Vladimir Fuka ---
Connected error:
gfortran -Wall -c ice7.f90
ice7.f90: In function âadd_element_polyâ:
ice7.f90:25:0: internal compiler error: in lhd_incomplete_type_error, at
langhooks.c:203
dummy = memcpy(loc(a(si
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57305
--- Comment #3 from Vladimir Fuka ---
The first one is incorrect code, the other one compiles with ifort 13.1.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57306
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56552
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56552
--- Comment #5 from rsandifo at gcc dot gnu.org
---
(In reply to rsand...@gcc.gnu.org from comment #4)
> I've probably missed the bigger picture here, but FWIW, I don't
> see any problem with extending *mov_on_
> to QI and HI. I suppose it would
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57307
Bug ID: 57307
Summary: ICE with sourced allocation with array constructor
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17314
--- Comment #17 from Jason Merrill ---
Actually, this seems to be issue 7:
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_closed.html#7
So we should reject the variant with a public constructor as well. It would be
good to get the same diagn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17314
--- Comment #18 from Jason Merrill ---
(In reply to Jason Merrill from comment #17)
> It would be good to get the same diagnostic as in comment #4.
And also give a warning about the private virtual base.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57279
Jason Merrill changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56547
Oleg Endo changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57266
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57304
mrs at gcc dot gnu.org changed:
What|Removed |Added
CC||mrs at gcc dot gnu.org
--- Comme
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49146
--- Comment #7 from Ben Woodard ---
Created attachment 30137
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30137&action=edit
t_repro.c compiled -g -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57297
--- Comment #5 from Mikael Morin ---
Created attachment 30138
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30138&action=edit
frontend patch, second try
This variant reduces the amount of VIEW_CONVERT_EXPR, which should make the
code less c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17314
--- Comment #19 from Paolo Carlini ---
I see, thanks.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57308
Bug ID: 57308
Summary: DF_REF_REAL_LOC segfault in web.c:union_match_dups
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57308
David Edelsohn changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57308
--- Comment #2 from Andrew Pinski ---
I think this is a dup of bug 57304.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57304
mrs at gcc dot gnu.org changed:
What|Removed |Added
CC||dje at gcc dot gnu.org
--- Comme
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57308
mrs at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57309
Bug ID: 57309
Summary: Spill code degrades vectorized loop for 437.leslie3d
on PPC64
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: missed-optimizatio
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50160
jandyu rata changed:
What|Removed |Added
CC||amandalionard at gmail dot com
--- Comment
83 matches
Mail list logo
