On 12.04.2012 18:22, Richard Guenther wrote:
2012/4/12 Andrey Belevantsev:
On 12.04.2012 17:54, Richard Guenther wrote:
2012/4/12 Andrey Belevantsev:
On 12.04.2012 16:38, Richard Guenther wrote:
On Thu, Apr 12, 2012 at 2:36 PM, Igor Zamyatin
wrote:
On Thu, Apr 12, 2012 at 4:24 PM, Ri
Hello,
On 07.03.2012 15:46, Alexander Monakov wrote:
On Wed, 7 Mar 2012, Andrey Belevantsev wrote:
Hello,
This PR is again about insns that are recog'ed as>=0 but do not change the
processor state. As explained in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52203#c8, I've tried experimenti
Hello,
For some versions and execution modes, VxWorks features facilities to let
users download object modules and link them with the kernel at run-time.
Relocation troubles (24bit reloc overflows) might show up when module
instructions contain short references to kernel symbols and the module
ha
Hello,
Here is a patch which creates new gnu-user-common.h file and moves all
common gnu-user.h and gnu-user64.h definitions to this new file. New
file is required to avoid duplication of Android specific changes in
gnu-user.h and gnu-user64.h. This patch is actually a non Android
specific part of
Richard,
this patch fixes PR52743.
The problem is as follows: blocks 3 and 5, with successor 6 are considered equal
and merged.
...
# BLOCK 3 freq:6102
# PRED: 2 [61.0%] (true,exec)
# VUSE <.MEMD.1734_10>
dddD.1710_3 = bbbD.1703;
goto ;
# SUCC: 6 [100.0%] (fallthru,exec)
# BLOCK
On Fri, Apr 13, 2012 at 12:11 AM, Aldy Hernandez wrote:
> Here we have a testcase that affects both the C++ memory model and
> transactional memory.
>
> [Hans, this is caused by the same problem that is causing the speculative
> register promotion issue you and Torvald pointed me at].
>
> In the f
On Fri, 13 Apr 2012, Andrey Belevantsev wrote:
> But of course I wrongly microoptimized the decision of whether an insn is
> "empty" as shown in PR 52715, so the right fix is to check the emptiness right
> before issuing the insn. Thus, the following patch is really needed (tested
> on ia64 and
On Fri, Apr 13, 2012 at 10:32 AM, Tom de Vries wrote:
> Richard,
>
> this patch fixes PR52743.
>
> The problem is as follows: blocks 3 and 5, with successor 6 are considered
> equal
> and merged.
> ...
> # BLOCK 3 freq:6102
> # PRED: 2 [61.0%] (true,exec)
> # VUSE <.MEMD.1734_10>
> dddD.1710
On Thu, 12 Apr 2012, Richard Guenther wrote:
>
> This fixes PR52549 - we are running into an overzealous assert
> that wants to make sure we don't have PLUS_EXPR on pointers.
> But that code does not really check this and falls foul of
> the conversion removal code right before it that transforms
Hello!
> Here is a patch which creates new gnu-user-common.h file and moves all
> common gnu-user.h and gnu-user64.h definitions to this new file. New
> file is required to avoid duplication of Android specific changes in
> gnu-user.h and gnu-user64.h. This patch is actually a non Android
> specif
Hello,
I think it is good to disable the exceptions for the division by zero. Maybe
this should be made target specific and not based on a configure option. For
example in "libgcc/config.host":
arm*-*-linux*)
[...]
tmake_file="${tmake_file} arm/t-div-by-zero-exc"
[..
On Thu, Apr 12, 2012 at 5:01 PM, Andrey Belevantsev wrote:
> On 12.04.2012 16:38, Richard Guenther wrote:
>>
>> On Thu, Apr 12, 2012 at 2:36 PM, Igor Zamyatin
>> wrote:
>>>
>>> On Thu, Apr 12, 2012 at 4:24 PM, Richard Guenther
>>> wrote:
On Thu, Apr 12, 2012 at 2:00 PM, Alexander Mona
> Hello!
>
>> Here is a patch which creates new gnu-user-common.h file and moves all
>> common gnu-user.h and gnu-user64.h definitions to this new file. New
>> file is required to avoid duplication of Android specific changes in
>> gnu-user.h and gnu-user64.h. This patch is actually a non Android
>
On 12/04/12 19:29, Dennis Gilmore wrote:
>
> off topic but i find aarch64 weird and too generic is it arm alpha amd
> atom.
>
That's only 'cos it's new. It's no different from names like ia64.
R.
On Fri, Apr 13, 2012 at 12:37 PM, Ilya Enkovich wrote:
>> Hello!
>>
>>> Here is a patch which creates new gnu-user-common.h file and moves all
>>> common gnu-user.h and gnu-user64.h definitions to this new file. New
>>> file is required to avoid duplication of Android specific changes in
>>> gnu-u
On 13/04/12 11:13, Richard Guenther wrote:
> On Fri, Apr 13, 2012 at 10:32 AM, Tom de Vries wrote:
>> Richard,
>>
>> this patch fixes PR52743.
>>
>> The problem is as follows: blocks 3 and 5, with successor 6 are considered
>> equal
>> and merged.
>> ...
>> # BLOCK 3 freq:6102
>> # PRED: 2 [61.
Hi DJ,
The optimization pass flag "TODO_dump_flag" has been removed (see
patch committed 2012-04-11) which was causing the RL78 backend to fail
to build. I am applying the following patch as an obvious fix.
Cheers
Nick
gcc/ChangeLog
2012-04-13 Nick Clifton
* config/rl78/rl78
On Fri, Apr 13, 2012 at 2:18 PM, Igor Zamyatin wrote:
> On Thu, Apr 12, 2012 at 5:01 PM, Andrey Belevantsev wrote:
>> On 12.04.2012 16:38, Richard Guenther wrote:
>>>
>>> On Thu, Apr 12, 2012 at 2:36 PM, Igor Zamyatin
>>> wrote:
On Thu, Apr 12, 2012 at 4:24 PM, Richard Guenther
On Fri, Apr 13, 2012 at 12:56 PM, Tom de Vries wrote:
> On 13/04/12 11:13, Richard Guenther wrote:
>> On Fri, Apr 13, 2012 at 10:32 AM, Tom de Vries
>> wrote:
>>> Richard,
>>>
>>> this patch fixes PR52743.
>>>
>>> The problem is as follows: blocks 3 and 5, with successor 6 are considered
>>> eq
> No, just the bits; programmers would need to do
> __atomic_...(..., __ATOMIC_RELEASE | HLE_RELEASE);
> I believe this is what you had in one of your versions of the patch. My
> suggestions was not about doing something new but instead a
> suggestions/poll for a resolution of the discussion.
Oh
On Thu, 12 Apr 2012, Martin Jambor wrote:
> Hi,
>
> On Wed, Apr 04, 2012 at 04:42:05PM +0200, Richard Guenther wrote:
> > On Wed, 4 Apr 2012, Martin Jambor wrote:
> >
> > > Hi everyone, especially Richi and Eric,
> > >
> > > I'd like to know what is your attitude to changing SRA's
> > > build_r
Richard Guenther writes:
>> Anyway, the patch I posted previously would risk re-introducing PR
>> 50386 and PR 50326, even though they are very unlikely with just
>> bit-fields. So my current working version is the following, but it
>> causes failure of libmudflap.c++/pass55-frag.cxx execution t
The following patch fixes the missed handling of TRUTH_NOT_EXPR
predicates in predicate_mem_writes and general combined predicates
which need gimplification.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
2012-04-13 Richard Guenther
PR tree-optimization/5296
On 13.04.2012 14:18, Igor Zamyatin wrote:
On Thu, Apr 12, 2012 at 5:01 PM, Andrey Belevantsev wrote:
On 12.04.2012 16:38, Richard Guenther wrote:
On Thu, Apr 12, 2012 at 2:36 PM, Igor Zamyatin
wrote:
On Thu, Apr 12, 2012 at 4:24 PM, Richard Guenther
wrote:
On Thu, Apr 12, 2012 at 2:
Hello,
On typical VxWorks environments, WindRiver integrated tools are used as
much if not more than gdb for debugging purposes.
These evolve at an industrial pace, traditionally not as fast as GCC
regarding the support of latest dwarf standards.
As of today, in our experience, the best compromi
On Wed, Apr 11, 2012 at 4:46 AM, Richard Guenther
wrote:
> On Tue, Apr 10, 2012 at 9:08 PM, NightStrike wrote:
>> On Tue, Apr 10, 2012 at 10:38 AM, Richard Guenther
>> wrote:
>>> On Tue, Apr 10, 2012 at 3:06 PM, JonY wrote:
On 4/10/2012 20:37, Richard Guenther wrote:
> On Tue, Apr 10,
Hello,
For several years now, Ada has support for a "Persistent_BSS" pragma
that let users place data in a ".persistent.bss" section. This section:
- needs to be treated as a bss section by the compiler (in particular,
to set flags that will prevent use of space in executable files)
- can be
Am 10.04.2012 14:32, schrieb Thomas Koenig:
Hello world,
this patch effectively trims the spaces from the string on
list-directed reads. This avoids the large overhead on
processing these spaces when reading from long lines.
Ping ** 0.4285714?
Hi,
currently we ICE when attempting to devirtualize a call to a virtual
method introduced in a descendant but with a base which is an ancestor
which does not have it. This is because fold_ctor_reference returns
constant zero when it cannot find the particular value in the provided
constructor wh
On Apr 13, 2012, at 3:51 AM, Bernhard Reutner-Fischer wrote:
> Ping.
Before advancing, has the problem that Rainer pointed out on March 19th with
your earlier patch been fixed?
Hello world,
this patch replaces a != '' with len_trim(a) != 0, to
speed up the comparison. It also introduces a bit of cleanup
in frontend-passes.c.
Regression-tested. OK for trunk?
Thomas
2012-04-13 Thomas Koenig
PR fortran/52537
* frontend-passes.c (optimize_op
On Fri, Apr 13, 2012 at 12:37 PM, Ilya Enkovich wrote:
> 2012-04-13 Enkovich Ilya
>
> * config/i386/gnu-user-common.h: New.
>
> * config/i386/gnu-user.h (CPP_SPEC): Moved to
> gnu-user-common.h.
> (CC1_SPEC): Likewise.
> (ENDFILE_SPEC): Likewise.
> (DE
On Fri, 13 Apr 2012, Martin Jambor wrote:
> Hi,
>
> currently we ICE when attempting to devirtualize a call to a virtual
> method introduced in a descendant but with a base which is an ancestor
> which does not have it. This is because fold_ctor_reference returns
> constant zero when it cannot f
On Apr 3, 2012, at 5:16 AM, Bernhard Reutner-Fischer wrote:
> The second part of implicitly doing cleanup-modules is to remove the now
> superfluous dg-final directives.
Ok once the issue Rainer pointed out is addressed. As for the ChangeLog, I'd
be tempted to list them as:
* gfortran.d
On Apr 13, 2012, at 5:30 AM, NightStrike wrote:
>> no warning from trunk. Which GCC version emits this warning?
> Looks like cygwin gcc 3.4.4
3.4.4 is a little old now.. We'd encourage an upgrade to a fine new
compiler... :-)
>
> Eventually I'll succeed in making tree-optimize.c empty. At least
> the pass stuff I'm interested in get's better now.
Decompozing tree-optimize was on my wishlist, too.
>
> Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
>
> Richard.
>
> 2012-04-12 Richard Guenther
>
>
On Fri, Apr 13, 2012 at 7:02 AM, Uros Bizjak wrote:
> On Fri, Apr 13, 2012 at 12:37 PM, Ilya Enkovich
> wrote:
>
>> 2012-04-13 Enkovich Ilya
>>
>> * config/i386/gnu-user-common.h: New.
>>
>> * config/i386/gnu-user.h (CPP_SPEC): Moved to
>> gnu-user-common.h.
>> (CC
On 04/13/2012 04:20 PM, Mike Stump wrote:
> On Apr 13, 2012, at 5:30 AM, NightStrike wrote:
>>> no warning from trunk. Which GCC version emits this warning?
>
>> Looks like cygwin gcc 3.4.4
>
> 3.4.4 is a little old now.. We'd encourage an upgrade to a fine new
> compiler... :-)
The thing is
On Fri, Apr 13, 2012 at 06:57:44AM -0700, Mike Stump wrote:
>On Apr 13, 2012, at 3:51 AM, Bernhard Reutner-Fischer wrote:
>> Ping.
>
>Before advancing, has the problem that Rainer pointed out on March 19th with
>your earlier patch been fixed?
I believe that it is fixed, yes. See r185688 and my fo
On Fri, Apr 13, 2012 at 7:34 AM, H.J. Lu wrote:
> On Fri, Apr 13, 2012 at 7:02 AM, Uros Bizjak wrote:
>> On Fri, Apr 13, 2012 at 12:37 PM, Ilya Enkovich
>> wrote:
>>
>>> 2012-04-13 Enkovich Ilya
>>>
>>> * config/i386/gnu-user-common.h: New.
>>>
>>> * config/i386/gnu-user.h (CPP
On Fri, Apr 13, 2012 at 04:33:17PM +0200, Bernd Schmidt wrote:
> On 04/13/2012 04:20 PM, Mike Stump wrote:
> > On Apr 13, 2012, at 5:30 AM, NightStrike wrote:
> >>> no warning from trunk. Which GCC version emits this warning?
> >
> >> Looks like cygwin gcc 3.4.4
> >
> > 3.4.4 is a little old now
On 04/13/2012 04:44 PM, Jakub Jelinek wrote:
> On Fri, Apr 13, 2012 at 04:33:17PM +0200, Bernd Schmidt wrote:
>> On 04/13/2012 04:20 PM, Mike Stump wrote:
>>> On Apr 13, 2012, at 5:30 AM, NightStrike wrote:
> no warning from trunk. Which GCC version emits this warning?
>>>
Looks like cygw
On Fri, Apr 13, 2012 at 10:20 AM, Mike Stump wrote:
> On Apr 13, 2012, at 5:30 AM, NightStrike wrote:
>>> no warning from trunk. Which GCC version emits this warning?
>
>> Looks like cygwin gcc 3.4.4
>
> 3.4.4 is a little old now.. We'd encourage an upgrade to a fine new
> compiler... :-)
Yea
On Fri, Apr 13, 2012 at 10:33 AM, Bernd Schmidt wrote:
> On 04/13/2012 04:20 PM, Mike Stump wrote:
>> On Apr 13, 2012, at 5:30 AM, NightStrike wrote:
no warning from trunk. Which GCC version emits this warning?
>>
>>> Looks like cygwin gcc 3.4.4
>>
>> 3.4.4 is a little old now.. We'd encour
On Apr 9, 2012, Eric Botcazou wrote:
> Could you add a comment for each value?
Done
> Missing "extern" for all declarations.
Thanks, added.
> I don't understand the "or _WITH_VALUE otherwise" part of the comment.
Sorry, my bad. It didn't make sense. Fixed.
> Please add a comment explaini
On Apr 9, 2012, Jakub Jelinek wrote, in response to
my posting to the wrong thread (now fixed):
> On Mon, Apr 09, 2012 at 03:29:05AM -0300, Alexandre Oliva wrote:
>> + && (!df_ignore_stack_reg (uregno)))
> Please remove the extra () around this line,
>
> On Fri, Apr 13, 2012 at 7:34 AM, H.J. Lu wrote:
>> On Fri, Apr 13, 2012 at 7:02 AM, Uros Bizjak wrote:
>>> On Fri, Apr 13, 2012 at 12:37 PM, Ilya Enkovich
>>> wrote:
>>>
2012-04-13 Enkovich Ilya
* config/i386/gnu-user-common.h: New.
* config/i386/gnu-
Il 13/04/2012 17:58, Alexandre Oliva ha scritto:
>
> I've just installed the patch, but if you find the need for any further
> improvement, let me know and I'll do it right away.
I wonder if it makes any sense to move the dead_debug_* stuff to its own
file...
Paolo
On Fri, Apr 13, 2012 at 01:57:33PM +0200, Rainer Orth wrote:
> Richard Guenther writes:
>
> >> Anyway, the patch I posted previously would risk re-introducing PR
> >> 50386 and PR 50326, even though they are very unlikely with just
> >> bit-fields. So my current working version is the following,
Hi,
This patch defines _ILP32 and __ILP32__ for x32 as specified by x32 psABI.
OK for trunk and 4.7 branch?
Thanks.
H.J.
---
2012-04-13 H.J. Lu
* config/i386/i386-c.c (ix86_target_macros): Define _ILP32
and __ILP32__ for x32.
diff --git a/gcc/config/i386/i386-c.c b/gcc/confi
On Wed, Apr 11, 2012 at 10:51, Thomas Koenig wrote:
> Hi,
>
>
>> this patch uses division by known sizes (which can usually be replaced
>> by a simple shift because intrinsics have sizes of power of two) instead
>> of division by the size extracted from the array descriptor itself.
>>
>> This shou
On Fri, Apr 13, 2012 at 7:14 PM, H.J. Lu wrote:
> This patch defines _ILP32 and __ILP32__ for x32 as specified by x32 psABI.
> OK for trunk and 4.7 branch?
> * config/i386/i386-c.c (ix86_target_macros): Define _ILP32
> and __ILP32__ for x32.
OK.
Thanks,
Uros.
Hi,
On Fri, Apr 13, 2012 at 04:13:13PM +0200, Richard Guenther wrote:
> On Fri, 13 Apr 2012, Martin Jambor wrote:
>
> > Hi,
> >
> > currently we ICE when attempting to devirtualize a call to a virtual
> > method introduced in a descendant but with a base which is an ancestor
> > which does not h
> The optimization pass flag "TODO_dump_flag" has been removed (see
> patch committed 2012-04-11) which was causing the RL78 backend to fail
> to build. I am applying the following patch as an obvious fix.
Ok, thanks!
C++11 extends unions so that a member can have a non-trivial default
constructor, but the union then has a deleted constructor unless the
user defines one. As a result, we can't assume that an anonymous union
has a trivial default constructor anymore.
Tested x86_64-pc-linux-gnu, applying to t
When a list-initialization doesn't quite match either a list constructor
or a non-list constructor, we end up trying to compare them in joust and
get confused because they have different numbers of parameters. So
let's just treat them as unordered; we're going to talk about what's
wrong with b
One case that I missed in my patch for PR 35722.
Tested x86_64-pc-linux-gnu, applying to trunk and 4.7.
commit 9fa7eea3608b19b53cc2f3c9a8195cf811b02d84
Author: Jason Merrill
Date: Fri Apr 13 13:37:26 2012 -0400
PR c++/52824
* pt.c (any_pack_expanson_args_p): New.
(coerce_templa
One case that I missed in my patch for PR 35722.
Tested x86_64-pc-linux-gnu, applying to trunk and 4.7.
commit 9fa7eea3608b19b53cc2f3c9a8195cf811b02d84
Author: Jason Merrill
Date: Fri Apr 13 13:37:26 2012 -0400
PR c++/52824
* pt.c (any_pack_expanson_args_p): New.
(coerce_templa
Tom> Here is a new patch for gcc.
Tom> I still haven't updated the src side, but there's little to do there
Tom> that isn't already done in this patch.
Tom> Ok?
Tom> Ping.
Ping.
Tom
On Apr 13, 2012, at 7:39 AM, Bernhard Reutner-Fischer wrote:
> On Fri, Apr 13, 2012 at 06:57:44AM -0700, Mike Stump wrote:
>> On Apr 13, 2012, at 3:51 AM, Bernhard Reutner-Fischer wrote:
>>> Ping.
>>
>> Before advancing, has the problem that Rainer pointed out on March 19th with
>> your earlier p
On Apr 13, 2012, at 7:50 AM, Bernd Schmidt wrote:
> The problem is that a human might be
> confused, for example due to bad indentation. Whether there's a for in
> between doesn't matter for this purpose, the following is most likely a bug:
>
> if ()
> for (..)
>if ()
> x
> else
> y
I
On Tue, Apr 10, 2012 at 11:21, Tobias Burnus
wrote:
> Regarding ABI breakage:
[snip]
In general I agree that ABI compatibility is something we should take
seriously, but OTOH we should take care that the anointed ABI makes
sense. Which IMHO would imply that known ABI bugs/misdesigns should be
fix
Hi Janne,
I thought I already approved this a few weeks ago
sorry, I totally missed that. Comes from having a computer
crash on you...
Thanks for the review!
Thomas
> -Original Message-
> From: Aldy Hernandez [mailto:al...@redhat.com]
> Sent: Thursday, April 12, 2012 3:12 PM
> To: Richard Guenther
> Cc: Andrew MacLeod; Boehm, Hans; gcc-patches; Torvald Riegel
> Subject: [PR tree-optimization/52558]: RFC: questions on store data
> race
>
> Here we ha
> From: Richard Guenther [mailto:richard.guent...@gmail.com]
> Can we _remove_ a store we percieve as redundant (with a single-threaded
> view) with the memory model?
Generally yes, so long as synchronization operations either conservatively
treated as completely opaque, or are treated correctly i
On Fri, 2012-04-13 at 16:50 +0200, Bernd Schmidt wrote:
> On 04/13/2012 04:44 PM, Jakub Jelinek wrote:
> > On Fri, Apr 13, 2012 at 04:33:17PM +0200, Bernd Schmidt wrote:
> >> On 04/13/2012 04:20 PM, Mike Stump wrote:
> >>> On Apr 13, 2012, at 5:30 AM, NightStrike wrote:
> > no warning from trun
On 06/03/12 15:21, Richard Guenther wrote:
> On Mon, Feb 13, 2012 at 1:36 PM, Tom de Vries wrote:
>> On 13/02/12 12:54, Richard Guenther wrote:
>>> On Thu, Feb 2, 2012 at 11:44 AM, Tom de Vries
>>> wrote:
Richard,
this patch fixes PR52801.
Consider test-case pr51879-12.c
67 matches
Mail list logo
