On Tue, 17 Jul 2012, Mike Stump wrote:
> In doing up the mods for the constant wide int code, we found a nasty
> including ordering problem that seems only tangentially related to our
> code. In options.h this is generated:
Maybe such prototypes in options.h, that don't actually depend on anyt
On Wed, Jul 18, 2012 at 1:05 AM, Alex Turjan wrote:
> I found the patch from the following link:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52250
See comment 9. The patch pasted in the audit trail is not what has
been committed.
Alexander
In doing up the mods for the constant wide int code, we found a nasty including
ordering problem that seems only tangentially related to our code. In
options.h this is generated:
/* Anything that includes tm.h, does not necessarily need this. */
#if !defined(GCC_TM_H)
#include "input.h" /* for
I found the patch from the following link:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52250
But i dont see the removal of the assert in move_bb_info.
Perhaps you have another patch related to this bug.
thanks
Alex
--- On Tue, 7/17/12, Alexander Monakov wrote:
> From: Alexander Monakov
> Subjec
On Tue, Jul 17, 2012 at 8:39 PM, Alex Turjan wrote:
>
> Hi,
> I tried the patch but it doesnt solve my problem.
> The patch addresses the problem on the else branch but my problem is on the
> if:
> if (can_merge_blocks_p (bb->prev_bb, bb))
> sel_merge_blocks ...
I don't understand. You said
Hi,
I tried the patch but it doesnt solve my problem.
The patch addresses the problem on the else branch but my problem is on the if:
if (can_merge_blocks_p (bb->prev_bb, bb))
sel_merge_blocks ...
Alex
--- On Tue, 7/17/12, Alexander Monakov wrote:
> From: Alexander Monakov
> Subject: Re: s
Alan Modra wrote:
> However, the "o" constraint rejects any offset >= 0x7ff4 due to
> rs6000_mode_dependent_address. This particular problem has been known
> for a long time, but that's not the only problem with "o" (and also
> the rs6000 "Y" constraint, a variant of "o"). A more subtle
> requir
> As a consequence inside sel_remove_empty_bb I hit on the following assert:
> gcc_assert (in_current_region_p (merge_bb));
Sounds like your GCC tree does not have Andrey's fix for PR 52250 (SVN
revision 184975).
Alexander
Hi,
I get an assert failure during a run of the selective scheduler.
The problem is due to the implementation of maybe_tidy_empty_bb.
Inside of it I see the following piece of code:
/* If it is possible - merge BB with its predecessor. */
if (can_merge_blocks_p (bb->prev_bb, bb))
sel_merge_blocks
This email is a result of delving into
https://bugzilla.redhat.com/show_bug.cgi?id=837630 an ICE when
building powerpc-linux gcc 4.7.1 with -fprofile-generate. I'm asking
for corrections/advice/guidance from anyone with a good working
knowledge of reload!
The ICE is
combine.c:5318:1: error: insn
On 7/17/2012 7:23 AM, Richard Guenther wrote:
On Tue, Jul 17, 2012 at 12:43 PM, wrote:
Hi all,
I would like to know if GCC provides an option to get a detailed report on the
optimization actually performed by the compiler. For example with the Intel C
compiler it is possible using the -opt-re
Steven Bosscher writes:
>> sparc-sun-solaris2.10,
>
> Perhaps Rainer Orth can help?
I see this has already been dealt with while I was away.
Rainer
--
-
Rainer Orth, Center for Biotechnology, Bielefeld Univers
On Tue, Jul 17, 2012 at 12:43 PM, wrote:
> Hi all,
> I would like to know if GCC provides an option to get a detailed report on
> the optimization actually performed by the compiler. For example with the
> Intel C compiler it is possible using the -opt-report. I don't want to look
> at the ass
Hi all,
I would like to know if GCC provides an option to get a detailed report on the
optimization actually performed by the compiler. For example with the Intel C
compiler it is possible using the -opt-report. I don't want to look at the
assembly file and figure out the optimization.
Thank yo
On Mon, Jul 16, 2012 at 8:23 PM, Jonathan Wakely wrote:
> On Jul 16, 2012 5:28 PM, "Dimitrios Apostolou" wrote:
>>
>> Hello,
>>
>> I'm trying to write a small script that shows emails addresses for all
>> committers of last year, for all files a patch touches. In the commit logs
>> however all c
15 matches
Mail list logo