Ping.
On Fri, Apr 6, 2012 at 2:15 PM, Terry Guo wrote:
> Hello,
>
> This simple patch is to enable GCC to accept new option -mcpu=cortex-m0plus
> in order to support newly released Cortex-M0+. Is it OK to trunk, 4.7 branch
> and 4.6 branch?
>
> BR,
> Terry
>
> 2012-04-06 Terry Guo
>
> *
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 should save about 20 cycles for a single calculation.
I'll go through the
Ping.
On 04/03/2012 01:59 PM, Tobias Burnus wrote:
A rather obvious patch.
The module procedure had the FL_PROCEDURE due its use ("CALL sub" or
"func()") - but no interface and no type. Thus, there was no attempt
to search for the symbol in the parent namespace, which causes failures.
Build
On Tue, 10 Apr 2012, Steven Bosscher wrote:
> On Tue, Apr 10, 2012 at 4:56 PM, Richard Guenther wrote:
> > I'm sure more RTL optimiziation fallout will pop up - and I wonder
> > if we should simply avoid modifying the CFG all over the place and
> > instead do that in cleanup_cfg. Thus, in the if
Am 11.04.2012 10:01, schrieb Tobias Burnus:
Ping.
OK.
Thanks for the patch!
Thomas
On 06/04/12 07:15, Terry Guo wrote:
> Hello,
>
> This simple patch is to enable GCC to accept new option -mcpu=cortex-m0plus
> in order to support newly released Cortex-M0+. Is it OK to trunk, 4.7 branch
> and 4.6 branch?
>
> BR,
> Terry
>
> 2012-04-06 Terry Guo
>
> * config/arm/arm-
On Tue, Apr 10, 2012 at 5:40 PM, Michael Matz wrote:
> Hi,
>
> On Tue, 10 Apr 2012, Steven Bosscher wrote:
>
>> This is OK.
>
> r186283.
>
>> Do you think it would be worthwhile to do this transformation in the
>> middle end too, based on profile information for values?
>
> I'd think so, but it pr
Hi Michael,
could you replace
+ if (shift< 0 || shift>= len)
by
> + if (unlikely(shift< 0 || shift>= len))
? This could save a few more cycles.
Thomas
On Tue, Apr 10, 2012 at 6:05 PM, Michael Matz wrote:
> Hi,
>
> On Tue, 10 Apr 2012, Richard Guenther wrote:
>
>> > + vec_inv = build_constructor (vectype, v);
>> > + new_temp = vect_init_vector (stmt, vec_inv, vectype, gsi);
>> > + new_stmt = SSA_NAME_DEF_STMT (new_temp);
>
On Tue, Apr 10, 2012 at 8:43 PM, Igor Zamyatin wrote:
> Hi All!
>
> Here is a patch that enables unroll at O2 for Atom.
>
> This gives good performance boost on EEMBC 2.0 (~+8% in Geomean for 32
> bits) with quite moderate code size increase (~5% for EEMBC2.0, 32
> bits).
5% is not moderate. You
Hi All!
It is known that imul placement is rather critical for Atom processors
and changes try to improve imul scheduling for Atom.
This gives +5% performance on several tests from new OA 2.0 testsuite
from EEMBC.
Tested for i386 and x86-64, ok for trunk?
ChangeLog:
2012-04-10 Yuri Rumyantse
On Tue, Apr 10, 2012 at 8:50 PM, David Edelsohn wrote:
> On Tue, Apr 10, 2012 at 1:36 PM, Peter Bergner wrote:
>
>> 2012-mm-dd Peter Bergner
>> Michael Matz
>>
>> gcc/
>> PR target/16458
>> * rtlanal.c (unsigned_reg_p): New function.
>> * rtl.h (unsigned_reg_p
On Tue, Apr 10, 2012 at 8:54 PM, Xinliang David Li wrote:
> Hi Richard, this is a follow up patch for more cleanups.
>
> Bootstrap and tested on x86-64/linux.
>
> Ok for trunk?
Ok.
Thanks,
Richard.
> thanks,
>
> David
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, 2012 at 2:15 PM, JonY wrote:
> Hi,
>
> Patch OK?
Hi Tobias,
> Hence, we should really think about -fabi-version= (and .mod
> compatibility).
> Unless, we are positive that we will break the ABI for the array descriptor in
> 4.8, I am in favour of adding -fabi-version= already for the proc-pointer
> patch.
>
> Comments?
well, my feeling is that
Now that diagnostics first point to the spelling location of tokens
coming from macro expansion, the test case
gcc/testsuite/g++.old-deja/g++.other/vaarg3.C shows that when I write
va_args (args, some_type), the location that is recorded for
"some_type" is not correct. We wrongly record a location
On Wed, Apr 11, 2012 at 6:15 AM, Alan Modra wrote:
> On Fri, Apr 06, 2012 at 05:25:15PM +0200, Olivier Hainque wrote:
>> Have you discovered where the problem you are still observing
>> is coming from (with another case on 4.4) ? I was planning to look
>> into it and realized that maybe you wer
>> PS: I lost track. Are there patches which still have to be reviewed?
>
> Seemingly: Plenty. Also, some reviewed patches seem to uncommitted.
Maybe it would make sense to reactivate
http://gcc.gnu.org/wiki/GFortranPatchTracker and collect the pending
patches there?
Cheers,
Janus
There are various conversion related warnings that trigger on
potentially dangerous uses of NULL (or __null). NULL is defined as a
macro in a system header, so calling warning or warning_at on a virtual
location of NULL yields no diagnostic. So the test accompanying this
patch (as well as others)
Hi,
this paragraph is inside the 'i386 type attributes' section, while it isn't
target specific.
This patch moves it at the end of the attribute list. Maybe we should remove
it completely
as there is an 'attribute syntax' section.
Ok for trunk ?
Tristan.
2012-04-11 Tristan Gingold
Bugger, missed the thread fork and didn't send this invitation to
everybody yet.
- Forwarded message from Steve McIntyre -
Date: Wed, 11 Apr 2012 02:06:09 +0100
From: Steve McIntyre
To: Jon Masters
Cc: cross-dis...@lists.linaro.org, Adam Conrad ,
linaro-toolch...@lists.linaro.o
Hi Janus,
On 04/11/2012 10:58 AM, Janus Weil wrote:
Hence, we should really think about -fabi-version= (and .mod compatibility).
Unless, we are positive that we will break the ABI for the array descriptor in
4.8, I am in favour of adding -fabi-version= already for the proc-pointer
patch.
Com
On Wed, Apr 11, 2012 at 11:33 AM, Tristan Gingold wrote:
> Hi,
>
> this paragraph is inside the 'i386 type attributes' section, while it isn't
> target specific.
>
> This patch moves it at the end of the attribute list. Maybe we should remove
> it completely
> as there is an 'attribute syntax'
This adds support for the new (Version 51.0) class file format. It
doesn't actually generate code for invokedynamic bcause we don't have
any runtime support yet, but it's a start. jcf-dump prints all of the
new attributes.
Andrew.
2012-04-11 Andrew Haley
* jcf.h (bootstrap_method):
Folks,
Thanks a lot for inputs and suggestions!
Here is updated version of patch.
ChangeLog entry:
2012-04-11 Kirill Yukhin
* builtins.c (get_memmodel): Remove check of upper bound.
(expand_builtin_atomic_compare_exchange): Mask memmodel values.
* config/i386/cpuid.h (b
On Apr 11, 2012, at 12:03 PM, Richard Guenther wrote:
> On Wed, Apr 11, 2012 at 11:33 AM, Tristan Gingold wrote:
>> Hi,
>>
>> this paragraph is inside the 'i386 type attributes' section, while it isn't
>> target specific.
>>
>> This patch moves it at the end of the attribute list. Maybe we s
Hi!
On Wed, Apr 11, 2012 at 02:35:38PM +0400, Kirill Yukhin wrote:
What is TARGET_HLE good for? I thought the point of HLE prefixes
is that they are silently ignored on older CPUs. So, HLE should be
always enabled IMHO. If you don't use __ATOMIC_HLE_* bits in __atomic_*
in your source, it won'
On 05/04/12 14:34, Dennis Gilmore wrote:
> Fedora at least plans to not support installing hfp and sfp on the same
> system, while not completely decided I don't think we will be
> supporting running 32 bit arm binaries on 64 bit arm. there is not
> a legacy support use case that I can think of i
Hi,
tested x86_64-linux, committed to mainline.
Thanks,
Paolo.
/
2012-04-11 Paolo Carlini
PR libstdc++/52931
* include/bits/functional_hash.h (struct hash): Remove definition.
* testsuite/20_util/hash/52931.cc: New.
Index: include/bits/functional_hash
On Wed, Apr 11, 2012 at 12:51 PM, Jakub Jelinek wrote:
> What is TARGET_HLE good for? I thought the point of HLE prefixes
> is that they are silently ignored on older CPUs. So, HLE should be
> always enabled IMHO. If you don't use __ATOMIC_HLE_* bits in __atomic_*
> in your source, it won't be
Hi,
The attached patch merges the SCHED_REORDER macro into the ready_reorder
function, since the macro is used only in that function.
Tested with 'make all-gcc'
OK?
Cheers,
Oleg
ChangeLog:
* config/sh/sh.c (SCHED_REORDER): Merge macro into ...
(ready_reorder): ... this
On Wed, 2012-04-11 at 10:43 +0200, Richard Guenther wrote:
> On Tue, Apr 10, 2012 at 8:50 PM, David Edelsohn wrote:
> > On Tue, Apr 10, 2012 at 1:36 PM, Peter Bergner wrote:
> >
> >> 2012-mm-dd Peter Bergner
> >>Michael Matz
> >>
> >> gcc/
> >>PR target/16458
> >>
Hi,
The attached patch removes the old if'ed out secondary reload code in
sh.h.
Tested with 'make all-gcc'
OK?
Cheers,
Oleg
ChangeLog:
* config/sh/sh.h: Remove old secondary reload code.
Index: gcc/config/sh/sh.h
===
--- g
Hi,
On Wed, 11 Apr 2012, Richard Guenther wrote:
> > But it would possibly be an interesting experiment already to do such
> > transformation generally (without profiling) and see what it gives on
> > some benchmarks. Just to get a feel what's on the plate.
>
> The question is, of course, why
On 04/10/2012 09:37 AM, Steve McIntyre wrote:
Aargh. Again, use of a standard triplet for arm hard-float was agreed
by all parties at the Plumbers' meeting last September. For exactly
this reason. Now it seems that a number of people have totally ignored
that consensus for the last six months.
M
This fixes the corresponding SJLJ part of preserving loops over
EH lowering. The unfortunate thing is, of course, that factoring
the SJLJ breaks the loop structure quite badly because we create
mutliple entry loops all over the place.
Well. That's a pre-existing missed optimization.
Kai bootst
For PR52621 we analyze a loop nest (for prefetching) and
end up with {(integer(kind=8)) {0, +, {2, +, 2}_2}_2, +, 1}_3
which we pass to various predicates in analyze_overlapping_iterations
(the loop nest has loop->num == 1, 2 and 3 are nested in it).
First, evolution_function_is_univariate_p retu
On Wed, Apr 11, 2012 at 12:22 PM, Andrew Haley wrote:
> This adds support for the new (Version 51.0) class file format. It
> doesn't actually generate code for invokedynamic bcause we don't have
> any runtime support yet, but it's a start. jcf-dump prints all of the
> new attributes.
This break
Dear all,
my recent patch for setting PRIVATE module variables and procedures to
TREE_PUBLIC()=0 had a flaw: I completely forgot about generic
interfaces. Even if the specific name is PRIVATE, the specific function
is still callable through the a (public) generic name.
Thanks to HJ for the r
> Tests passing, bootstrap in progress.
>
> Comments?
Do you really imply ACQUIRE/RELEASE with HLE_ACQUIRE/RELEASE now? I don't
see that in the code. I think that's really required, otherwise the optimizer
will do the wrong thing and move memory references outside the region.
I second Jakub in d
Oleg Endo wrote:
>> BTW, do you have the numbers of CSiBE with this?
>>
>
> Only for "-m4-single -ml -O2 -mpretend-cmove" so far.
> Not so spectacular :T
> I'll also do a comparison of more variants to see if something went
> really bad. It's a bit difficult to isolate the degradations because
Oleg Endo wrote:
> The attached patch removes the old if'ed out secondary reload code in
> sh.h.
> Tested with 'make all-gcc'
> OK?
OK.
Regards,
kaz
Oleg Endo wrote:
> The attached patch merges the SCHED_REORDER macro into the ready_reorder
> function, since the macro is used only in that function.
> Tested with 'make all-gcc'
> OK?
OK.
Regards,
kaz
On Wed, Apr 11, 2012 at 03:06:35PM +0200, Andi Kleen wrote:
> Do you really imply ACQUIRE/RELEASE with HLE_ACQUIRE/RELEASE now? I don't
> see that in the code. I think that's really required, otherwise the optimizer
> will do the wrong thing and move memory references outside the region.
IMHO the
On 04/11/2012 01:43 PM, Richard Guenther wrote:
> This breaks bootstrap for me:
>
> In file included from
> /space/rguenther/src/svn/trunk/gcc/java/jcf-parse.c:1009:0:
> /space/rguenther/src/svn/trunk/gcc/java/jcf-reader.c:550:1: error:
> 'int jcf_parse_bootstrap_methods(JCF*, int)' defined but not
On Wed, Apr 11, 2012 at 03:12:44PM +0200, Jakub Jelinek wrote:
> On Wed, Apr 11, 2012 at 03:06:35PM +0200, Andi Kleen wrote:
> > Do you really imply ACQUIRE/RELEASE with HLE_ACQUIRE/RELEASE now? I don't
> > see that in the code. I think that's really required, otherwise the
> > optimizer
> > will
Ping?
2012/4/5 Kai Tietz :
> Hello,
>
> this patch adds some basic folding capabilities to fold-const for
> equal and none-equal comparisons
> on integer typed argument.
>
> ChangeLog
>
> 2012-04-05 Kai Tietz
>
> * fold-const.c (fold_comparison_1): New
> function.
> (fold_c
On Wed, Apr 11, 2012 at 3:46 AM, Dodji Seketeli wrote:
> There are various conversion related warnings that trigger on
> potentially dangerous uses of NULL (or __null). NULL is defined as a
> macro in a system header, so calling warning or warning_at on a virtual
> location of NULL yields no diag
Richard Guenther writes:
>
> 5% is not moderate. Your patch does enable unrolling at -O2 but not -O3,
> why? Why do you disable register renaming? check_imull requires a function
> comment.
>
> This completely looks like a hack for EEMBC2.0, so it's definitely not ok.
>
> -O2 is not supposed to
On Wed, Apr 11, 2012 at 3:59 AM, Dodji Seketeli wrote:
> Now that diagnostics first point to the spelling location of tokens
> coming from macro expansion, the test case
> gcc/testsuite/g++.old-deja/g++.other/vaarg3.C shows that when I write
> va_args (args, some_type), the location that is record
Igor Zamyatin writes:
> Hi All!
>
> It is known that imul placement is rather critical for Atom processors
> and changes try to improve imul scheduling for Atom.
>
> This gives +5% performance on several tests from new OA 2.0 testsuite
> from EEMBC.
>
> Tested for i386 and x86-64, ok for trunk?
On 04/10/2012 10:55 AM, Dodji Seketeli wrote:
+ if (CPP_OPTION (pfile, track_macro_expansion))
I think this should check context->tokens_kind rather than the compiler
flag.
Jason
On 04/10/2012 10:57 AM, Dodji Seketeli wrote:
+virt_loc = *(context->c.mc->cur_virt_loc - 1);
Style nit: I'd use [-1] here. OK with that change.
Jason
On Wed, 2012-04-11 at 22:10 +0900, Kaz Kojima wrote:
> Oleg Endo wrote:
> >> BTW, do you have the numbers of CSiBE with this?
> >>
> >
> > Only for "-m4-single -ml -O2 -mpretend-cmove" so far.
> > Not so spectacular :T
> > I'll also do a comparison of more variants to see if something went
> > r
On 04/10/2012 03:42 PM, Dodji Seketeli wrote:
In that case, besides returning NULL, enter_macro_context sets
pfile->context->c.macro to NULL, making cpp_get_token_1 forget to set
the location of the "vari" to the expansion point of A.
This seems like a bug that should be fixed rather than worke
On 04/10/2012 03:49 PM, Dodji Seketeli wrote:
Apparently, quite some places in the compiler (like the C/C++
preprocessor, the debug info machinery) expect expand_location to
resolve to locations that are in the main source file, even if the
token at stake comes from a macro that was defined in a
Good thought. OK.
Jason
OK.
Jason
I'm working on a target where intptr_t and pointers are larger than
size_t and ptrdiff_t. The testsuite has problems in this area, since we
often use the latter two types for casting from/to pointers, leading to
unwanted warnings. In some cases I've checked the corresponding PRs and
found that the
This is another problem I found working on a new target. In fold-const,
when folding conversions, there are two instances where mode bitsizes
are compared to type precisions. This fails to do the right thing if
mode precision and bitsize differ (which I believe they currently don't
on any target).
On Apr 11, 2012, at 3:55 PM, Bernd Schmidt wrote:
> I'm working on a target where intptr_t and pointers are larger than
> size_t and ptrdiff_t. The testsuite has problems in this area, since we
> often use the latter two types for casting from/to pointers, leading to
> unwanted warnings. In some
On 04/11/2012 04:02 PM, Tristan Gingold wrote:
>
> On Apr 11, 2012, at 3:55 PM, Bernd Schmidt wrote:
>
>> I'm working on a target where intptr_t and pointers are larger than
>> size_t and ptrdiff_t. The testsuite has problems in this area, since we
>> often use the latter two types for casting fr
On Wed, Apr 11, 2012 at 3:38 PM, Andi Kleen wrote:
> Igor Zamyatin writes:
>
>> Hi All!
>>
>> It is known that imul placement is rather critical for Atom processors
>> and changes try to improve imul scheduling for Atom.
>>
>> This gives +5% performance on several tests from new OA 2.0 testsuite
On 02/10/2012 08:01 PM, Vladimir Makarov wrote:
> On 02/08/2012 10:01 AM, Bernd Schmidt wrote:
>> We found a scheduler problem while testing Coldfire targets. The
>> prune_ready_list function I introduced doesn't take SCHED_GROUPs into
>> account, which can lead to a random insn being scheduled bet
On Wed, Apr 11, 2012 at 3:59 PM, Bernd Schmidt wrote:
> This is another problem I found working on a new target. In fold-const,
> when folding conversions, there are two instances where mode bitsizes
> are compared to type precisions. This fails to do the right thing if
> mode precision and bitsiz
The order of calls to sched_rgn_init and sched_init differs between
sched-rgn and sel-sched. This caused a scheduler patch I was working on
to segfault once sel-sched was enabled. The following patch swaps the
two function calls.
Bootstrapped & tested on i686-linux. Ok?
Bernd
* sel-sched
"H.J. Lu" writes:
> Hi,
>
> CSE turns (reg:DI 64)
>
> (insn 6 3 7 2 (set (reg:DI 64)
> (sign_extend:DI (subreg/u:SI (reg/v/f:DI 63 [ addr ]) 0))) x.i:6 122
> {*extendsidi2_rex64} (nil))
>
> into (reg/f:DI 64 [ addr ]). But nonzero_bits1 in rtlanal.c has
>
> #if defined(POINTERS_EXTEND_UNS
On Wed, Apr 11, 2012 at 4:16 PM, Bernd Schmidt wrote:
> The order of calls to sched_rgn_init and sched_init differs between
> sched-rgn and sel-sched. This caused a scheduler patch I was working on
> to segfault once sel-sched was enabled. The following patch swaps the
> two function calls.
>
> Bo
I stumbled over the following hunk in one of my pending patches
Index: gcc/tree-ssa-loop-prefetch.c
===
--- gcc/tree-ssa-loop-prefetch.c.orig 2011-10-12 13:14:10.0
+0200
+++ gcc/tree-ssa-loop-prefetch.c2012-02-23 1
On 12/23/2011 05:31 PM, Vladimir Makarov wrote:
> On 12/21/2011 09:09 AM, Bernd Schmidt wrote:
>> This patch was an experiment to see if we can get the same improvement
>> with modifications to IRA, making it more tolerant to over-aggressive
>> scheduling. THe idea is that if an instruction sets a
On 04/11/2012 10:08 AM, Bernd Schmidt wrote:
On 02/10/2012 08:01 PM, Vladimir Makarov wrote:
On 02/08/2012 10:01 AM, Bernd Schmidt wrote:
We found a scheduler problem while testing Coldfire targets. The
prune_ready_list function I introduced doesn't take SCHED_GROUPs into
account, which can lea
We sometimes get to invoke Makefile targets with a CC variable value containing
spaces (for extra options, typically). This causes failure at some stages on
powerpc-aix from mh-ppc-aix which has
LDFLAGS = `case $(CC) in *gcc*) echo -Wl,-bbigtoc ;; esac;`
The problem is the expansion of spaces a
This pattern is of type load, but the operands don't match the pattern
found in other load insns, so we must explicitly set op_pattern to
unknown. Committed.
Bernd
Index: gcc/ChangeLog
===
--- gcc/ChangeLog (revision 186325)
++
On Apr 11, 2012, at 7:04 AM, Bernd Schmidt wrote:
> On 04/11/2012 04:02 PM, Tristan Gingold wrote:
>>
>> On Apr 11, 2012, at 3:55 PM, Bernd Schmidt wrote:
>>> I'm working on a target where intptr_t and pointers are larger than
>>> size_t and ptrdiff_t. The testsuite has problems in this area, sinc
On Apr 11, 2012, at 6:55 AM, Bernd Schmidt wrote:
> I'm working on a target where intptr_t and pointers are larger than
> size_t and ptrdiff_t.
Hum, we question your sanity :-)
> Ok?
Ok. I hope you tested it on your target too!
On Apr 11, 2012, at 4:52 PM, Mike Stump wrote:
> On Apr 11, 2012, at 7:04 AM, Bernd Schmidt wrote:
>> On 04/11/2012 04:02 PM, Tristan Gingold wrote:
>>>
>>> On Apr 11, 2012, at 3:55 PM, Bernd Schmidt wrote:
I'm working on a target where intptr_t and pointers are larger than
size_t and
On Apr 11, 2012, at 6:59 AM, Bernd Schmidt wrote:
> This is another problem I found working on a new target. In fold-const,
> when folding conversions, there are two instances where mode bitsizes
> are compared to type precisions. This fails to do the right thing if
> mode precision and bitsize dif
Yet another iteration :)
>> > Do you really imply ACQUIRE/RELEASE with HLE_ACQUIRE/RELEASE now? I don't
Sorry, Andi. Added. So, at the moment you can do smth like
__atomic_compare_exchange_n (p, &oldv, newv, 0,
__ATOMIC_HLE_ACQUIRE, __ATOMIC_ACQUIRE);
And will get __ATOMIC_ACQUIRE model as well
Andrew Haley writes:
> On 04/11/2012 01:43 PM, Richard Guenther wrote:
>> This breaks bootstrap for me:
>>
>> In file included from
>> /space/rguenther/src/svn/trunk/gcc/java/jcf-parse.c:1009:0:
>> /space/rguenther/src/svn/trunk/gcc/java/jcf-reader.c:550:1: error:
>> 'int jcf_parse_bootstrap_meth
On Wed, Apr 11, 2012 at 07:52:59PM +0400, Kirill Yukhin wrote:
> Yet another iteration :)
>
> >> > Do you really imply ACQUIRE/RELEASE with HLE_ACQUIRE/RELEASE now? I don't
> Sorry, Andi. Added. So, at the moment you can do smth like
> __atomic_compare_exchange_n (p, &oldv, newv, 0,
> __ATOMIC_H
On Wed, Apr 11, 2012 at 06:06:58PM +0200, Andi Kleen wrote:
> +static unsigned HOST_WIDE_INT
> +ix86_extend_hle_macro (unsigned HOST_WIDE_INT memmodel)
> +{
> + unsigned HOST_WIDE_INT result = memmodel;
> +
> + if (memmodel & IX86_HLE_ACQUIRE)
> +result |= MEMMODEL_ACQUIRE;
> +
> + if (memmo
> I actually think it is a bad idea to imply any memory model
> from the HLE bits. If anything, we should warn for memmodel
> + hle bit combinations that are unlikely to DTRT.
This would be a warning with _RELAXED/_CONSUME, but there may be very
obscure situations where someone really wants that
On Wed, Apr 11, 2012 at 06:18:56PM +0200, Andi Kleen wrote:
> > I actually think it is a bad idea to imply any memory model
> > from the HLE bits. If anything, we should warn for memmodel
> > + hle bit combinations that are unlikely to DTRT.
>
> This would be a warning with _RELAXED/_CONSUME, but
On Tue, Apr 3, 2012 at 2:02 PM, Ilya Enkovich wrote:
>> On Tue, Apr 3, 2012 at 3:49 AM, Ilya Enkovich wrote:
On 3/04/2012, at 2:16 AM, Ilya Enkovich wrote:
>>
>> The point is that one can build a toolchain for i686-linux-gnu that will
>> support both 32-bit and 64-bit multi
This patch makes the branch to build in C++ mode by default.
Tested on x86_64. Committed.
ChangeLog.cxx-conversion
* configure.ac (ENABLE_BUILD_WITH_CXX): Default to 'yes'.
* configure: Regenerate.
gcc/ChangeLog.cxx-conversion
* configure.ac (ENABLE_BUILD_WITH_CXX): Def
> But such a model isn't possible. The HLE bits are just some high bits
> ored into the memory model enum. So, if you use
> __ATOMIC_HLE_ACQUIRE, it is the same thing as
> __ATOMIC_HLE_ACQUIRE | __ATOMIC_RELAXED and thus it is a relaxed xacquire,
> not xacquire with default memory model.
> __atom
On Tue, Apr 10, 2012 at 1:33 PM, Manuel López-Ibáñez
wrote:
> On 10 April 2012 21:41, Manuel López-Ibáñez wrote:
>> On 10 April 2012 21:31, Jason Merrill wrote:
>>> On 04/10/2012 12:46 PM, Manuel López-Ibáñez wrote:
+ max_width = context->caret_max_width;
+ if (max_width<= 0)
>>
On 04/11/2012 04:57 PM, Rainer Orth wrote:
> Ok for mainline?
>
> Rainer
>
>
> 2012-04-11 Rainer Orth
>
> * jcf-dump.c (print_constant): Cast JPOOL_USHORT2, JPOOL_USHORT1
> results to long to match formats.
Sure. Sorry for the noise.
I wonder what we're supposed to do ab
Hi,
SUBTARGET_OVERRIDE_OPTIONS and SUBSUBTARGET_OVERRIDE_OPTIONS may depend
on TARGET_64BIT. This patch moves their handling after TARGET_64BIT
is updated. Tested on Linux/x86-64. OK for trunk?
Thanks.
H.J.
---
2012-04-10 H.J. Lu
* config/i386/i386.c (ix86_option_override_internal
Hi Janus:
> I would surely appreciate some input from others, also from users (in
> particular from Andrew as the bug reporter). In general: Is ABI
> compatibility of different gfortran versions important to gfortran
> users? (For me personally, as a user, not so much. I usually don't
> link my ow
On Wed, Apr 11, 2012 at 7:21 AM, Richard Sandiford
wrote:
> "H.J. Lu" writes:
>> Hi,
>>
>> CSE turns (reg:DI 64)
>>
>> (insn 6 3 7 2 (set (reg:DI 64)
>> (sign_extend:DI (subreg/u:SI (reg/v/f:DI 63 [ addr ]) 0))) x.i:6 122
>> {*extendsidi2_rex64} (nil))
>>
>> into (reg/f:DI 64 [ addr ]).
On Tue, Apr 10, 2012 at 8:15 PM, Mike Frysinger wrote:
> On Tuesday 10 April 2012 12:46:49 Michael Edwards wrote:
>> That way I can grandfather in binaries with ABI-ignorant
>> hard-coded library paths, and still handle ISA variants. The
>> "extranoise" might be "neon", or "ssse3"
>
> aren't ISA
On Wed, Apr 11, 2012 at 7:00 PM, H.J. Lu wrote:
> SUBTARGET_OVERRIDE_OPTIONS and SUBSUBTARGET_OVERRIDE_OPTIONS may depend
> on TARGET_64BIT. This patch moves their handling after TARGET_64BIT
> is updated. Tested on Linux/x86-64. OK for trunk?
>
> 2012-04-10 H.J. Lu
>
> * config/i386/
Dodji's final patch for 45088 fixed the GDB regression, but as Jakub
recently pointed out to me, we still end up with redundant
DW_TAG_pointer_types in some cases, with one for pointer-to-class and
the other for pointer-to-injected-class-name. We strip the
injected-class-name in dwarf2out so t
We can't talk about the type if there is no type.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit bc94f519583cdfc705c1bde750a06bbd42537193
Author: Jason Merrill
Date: Wed Apr 11 10:08:37 2012 -0400
PR c++/52906
* decl.c (check_tag_decl): Don't complain about attributes if we
On Wed, Apr 11, 2012 at 01:48:57PM -0400, Jason Merrill wrote:
> We can't talk about the type if there is no type.
>
> Tested x86_64-pc-linux-gnu, applying to trunk.
Shouldn't this go to 4.7 too?
> commit bc94f519583cdfc705c1bde750a06bbd42537193
> Author: Jason Merrill
> Date: Wed Apr 11 10:0
On 04/11/2012 07:31 PM, Peter Bigot wrote:
> The biggest one is that widening from 20-bit to 32-bit is an extremely
> expensive operation: it was a 16-bit ISA, but some newer MCUs support
> an extension with 20 bits in each register and a set of new
> instructions that must be used to preserve the
In 11 April 2012 18:40, H.J. Lu wrote:
>
> It breaks library tests:
>
> ERROR: tcl error sourcing
> ../../../../src-trunk/boehm-gc/testsuite/../../gcc/testsuite/lib/prune.exp.
> ERROR: tcl error sourcing
> ../../../../src-trunk/libgomp/testsuite/../../gcc/testsuite/lib/prune.exp.
> ERROR: tcl erro
On Wed, Apr 11, 2012 at 11:15 AM, Manuel López-Ibáñez
wrote:
> So how can I say in tcl "if not defined VAR then set VAR ""?
if ![info exists VAR] {
set VAR XXX
}
Thanks,
Andrew Pinski
On Wed, Apr 11, 2012 at 06:40:03PM +0200, Andi Kleen wrote:
> > But such a model isn't possible. The HLE bits are just some high bits
> > ored into the memory model enum. So, if you use
> > __ATOMIC_HLE_ACQUIRE, it is the same thing as
> > __ATOMIC_HLE_ACQUIRE | __ATOMIC_RELAXED and thus it is a
1 - 100 of 129 matches
Mail list logo
