On 02/15/2013 06:40 PM, Jason Merrill wrote:
The patch is OK. To deal with the warning, I would suggest putting
the constrained type somewhere other than ENUM_UNDERLYING_TYPE that's
shared between enums with fixed and non-fixed underlying types; having
it in ENUM_UNDERLYING_TYPE isn't really c
The branch was merged with trunk @ r196091.
Successfully bootstrapped on x86-64.
Committed as rev. 196099.
On Feb 15, 2013, at 11:44 AM, Chao-Ying Fu wrote:
> I know this, but it's very hard to educate people and let people admit it's
> not CPU's fault,
> when same software can run on other architectures.
Show us the link were you tried. Some of might be happy to help beat on them.
If you've not t
On Feb 15, 2013, at 11:15 AM, Seth LaForge wrote:
> On Fri, Feb 15, 2013 at 10:41 AM, Richard Earnshaw wrote:
>> On 15/02/13 18:33, Seth LaForge wrote:
>>> If so, I could certainly change the test to use a regexp, or inline it
>>> all of the ARM handlers in the case statement below.
>>
>> Yes, a
n0 "__builtin___asan_report_load" 6
at both -m32 and -m64. The no-redundant-instrumentation-7.s from the failing
-m64
test case is attached, generated with...
#
/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/testsuite/g++/../../xg++
-B/sw/src/fink.build/gcc48-4.8.0-1000/darwi
gcc 4.7.2 generates incorrect code for big-endian ARM VFP processors
when storing a local double to a packed memory location, as described
in bug 56351.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56351
A fix has been submitted to the trunk by Julian Brown:
http://gcc.gnu.org/git/?p=gcc.git;a=patc
On Feb 15, 2013, at 10:33 AM, Seth LaForge wrote:
> I was under the impression that gcc target specs were always triplets;
:-) arm-elf is a target spec, as is i960. There is a canonicalization that
takes place that can change the format of it to be more standardized. One or
more characters i
Hi,
The attached patch fixes the scanning of the not insn in the test case,
as suggested by Kaz in the PR.
Tested with
make -k check-gcc RUNTESTFLAGS="sh.exp=pr54685.c --target_board=sh-sim
\{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}"
applied as obvious to trunk.
Cheers,
Oleg
2013/2/15 François Dumont :
> Hi
>
> I had a problem with the result of
> std::is_copy_assignable>::type which used to be
> true_type. So here is a patch to fix that.
This patch would break with the requirements of the library. In
particular it would prevent that std::pair's of references are
Hi
I had a problem with the result of
std::is_copy_assignable>::type which used to
be true_type. So here is a patch to fix that.
2013-02-15 François Dumont
* include/bits/stl_pair.h (pair): Use default implementation for
copy and move constructors.
* testsuite/20_util/pair
Hello,
This PR uncovers an issue my latest optimization patch on Address
Sanitizer introduced.
This is in the context of instrumenting an access to a memory region,
like in:
void
foo (char *a, char *b, int s)
{
__builtin_memmove (a, b, s);
}
In this case, asan has to instr
Maciej W. Rozycki wrote:
>
> On Thu, 14 Feb 2013, Richard Sandiford wrote:
>
> > What about 64-bit targets? We can sometimes access doubles
> using GPRs,
> > so on 64-bit targets we could end up using LD and SD to
> access a double
> > even when this option disables LDC1 and SDC1. I think we'
Like 52026, the problem here is that we have a reference to an outer
variable in the lambda and can't instantiate it properly. And like
52026, the solution is to look up the variable again at instantiation time.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 43d4443096a0dbb9e9424370f010
The following patch fixes PR56348. The details of the problem are given on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56348
The patch was successfully bootstrapped and tested on x86/x86-64.
Committed as rev. 196090.
2013-02-15 Vladimir Makarov
PR rtl-optimization/56348
*
On Fri, Feb 15, 2013 at 10:41 AM, Richard Earnshaw wrote:
> On 15/02/13 18:33, Seth LaForge wrote:
>> If so, I could certainly change the test to use a regexp, or inline it
>> all of the ARM handlers in the case statement below.
>
> Yes, anything with linux in it will now be a quadruplet. There m
This patch from Janne Snabb changes libgo to use MAP_NORESERVE when
allocating the large memory arena. This makes no difference on
GNU/Linux but reportedly helps on OpenIndiana and OpenSolaris.
Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
Committed to mainline.
Ian
diff -r 3827
On 15/02/13 18:33, Seth LaForge wrote:
On Fri, Feb 15, 2013 at 10:28 AM, Richard Earnshaw wrote:
On 15/02/13 18:20, Seth LaForge wrote:
+# Handle big-endian ARM architectures.
+case ${target} in
+arm*b-*-*)
+ tm_defines="${tm_defines} TARGET_BIG_ENDIAN_DEFAULT=1"
+ ;;
Not ok. Th
On Fri, Feb 15, 2013 at 10:28 AM, Richard Earnshaw wrote:
> On 15/02/13 18:20, Seth LaForge wrote:
>> +# Handle big-endian ARM architectures.
>> +case ${target} in
>> +arm*b-*-*)
>> + tm_defines="${tm_defines} TARGET_BIG_ENDIAN_DEFAULT=1"
>> + ;;
>
> Not ok. This would mismatch on
>
>
On 15/02/13 18:20, Seth LaForge wrote:
Currently, for arm-* archs, TARGET_BIG_ENDIAN_DEFAULT is only set in
the case branch for arm*-*-linux-*, not for other arm architectures.
We're compiling for the TI TMS570, which is a big-endian processor,
with target set to armeb-unknown-eabi. The followin
The patch is OK. To deal with the warning, I would suggest putting the
constrained type somewhere other than ENUM_UNDERLYING_TYPE that's shared
between enums with fixed and non-fixed underlying types; having it in
ENUM_UNDERLYING_TYPE isn't really correct anyway.
Jason
Currently, for arm-* archs, TARGET_BIG_ENDIAN_DEFAULT is only set in
the case branch for arm*-*-linux-*, not for other arm architectures.
We're compiling for the TI TMS570, which is a big-endian processor,
with target set to armeb-unknown-eabi. The following patch moves the
big-endian check out of
Hi, thanks for your patch, and sorry it took me so long to respond.
On 08/18/2012 11:02 AM, Jiří Paleček wrote:
The idea of the fix is to postpone the decision whether or not to
capture later to the template instantiation. This is because until then,
we cannot know if the variable fulfills the c
When we remove __builtin_pow statements as part of reassociation, we
have to unlink the associated VDEF. We've always done this when we
directly remove the statement. However, in reassociation the statements
are sometimes modified in place instead of removed, potentially leaving
one or more dangl
Looks good, just a few nits. But please wait for Richard's feedback on it.
Will do.
+ this_fn_optabs = fn->optabs ? (struct target_optabs *) fn->optabs
+ : this_target_optabs;
I'd prefer : here be below ? on the line above it.
Blame emacs. I use whatever indentation i
On Fri, Feb 15, 2013 at 11:23:01AM -0600, Aldy Hernandez wrote:
> +2013-02-15 Aldy Hernandez
> + Jakub Jelinek
> +
> + PR target/52555
> + * genopinit.c (raw_optab_handler): Use this_fn_optabs.
> + (swap_optab_enable): Same.
> + (init_all_optabs): Use argument instead o
There's no need to track this on the decl, as the decl's type still
reflects the constness of the declaration. The issue is that the const
applies to the array element type rather than the array type itself, so
the code in dwarf2out.c needs to be fixed to find it there.
Jason
Actually, thinking more about SWITCHABLE_TARGETS, I don't think this works
at all on those targets. this_target_optab is some random optab from
whatever has been left there by previous function, it can be either the
Eeech... this significantly complicates things.
After some further interacti
We were adjusting the EH specification for destructors before looking at
the base classes, so we hadn't yet noticed that there was a non-trivial
base destructor to make things more complicated.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 799ff49ea8aa959deed277b590954bc3ef8253d2
Author
On Thu, Feb 14, 2013 at 11:45 PM, Konstantin Serebryany
wrote:
>
> Unfortunately, the test does not work if gold is the system linker.
> Any suggestion on how to make the test work with either linker?
I don't know of a way to set the address of the text segment for both
GNU ld and gold. As you h
On Fri, Feb 15, 2013 at 01:23:14AM +, Maciej W. Rozycki wrote:
> > What about 64-bit targets? We can sometimes access doubles using GPRs,
> > so on 64-bit targets we could end up using LD and SD to access a double
> > even when this option disables LDC1 and SDC1. I think we'd need to
> > pat
On Thu, Feb 14, 2013 at 05:48:57AM -0700, Jeff Law wrote:
> I think two tests should be sufficient. First, compile a simple
> program with -g and verify it generates dwarf2 debug records.
> Second verify that there aren't any -g options, unless is
> dwarf2.
>
> I'm actually on PTO today/tomorrow
On Fri, Feb 15, 2013 at 3:04 AM, Richard Biener
wrote:
> Note that there is no such thing as a "middle-end" or "back-end" type.
but we do conceptually have them.
-- Gaby
Gerald,
Is it ok for wwwdocs?
Thanks,
Igor
On Wed, Feb 13, 2013 at 3:21 PM, Uros Bizjak wrote:
> On Wed, Feb 13, 2013 at 12:17 PM, Igor Zamyatin wrote:
>>>
>>> Please also mention new -mfxsr, -mxsave and -mxsaveopt options.
>>>
New built-in functions to detect run-time CPU type and
I've submitted http://llvm.org/viewvc/llvm-project?view=revision&revision=175263
If it survives a few days of testing I'll do another merge to gcc.
--kcc
On Fri, Feb 15, 2013 at 1:47 PM, Konstantin Serebryany
wrote:
> On Fri, Feb 15, 2013 at 1:37 PM, Jakub Jelinek wrote:
>> On Fri, Feb 15, 2013
Ping
http://gcc.gnu.org/ml/gcc-patches/2013-01/msg01418.html
Probably for 4.9 now...
Thanks,
Kyrill
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Kyrylo Tkachov
> Sent: 30 January 2013 09:25
> To: gcc-patches@gcc.gnu.org
Le 14/02/2013 15:50, Tobias Burnus a écrit :
> additionally, I tested and found
> out that matrix-scalar/scalar-matrix was mishandled.
Indeed, thanks.
>
> Build and regtested on x86-64-gnu-linux.
> OK for the trunk and the 4.6 and 4.7 branches?
OK. (obvious actually)
Mikael
On Fri, Feb 15, 2013 at 1:37 PM, Jakub Jelinek wrote:
> On Fri, Feb 15, 2013 at 01:30:18PM +0400, Konstantin Serebryany wrote:
>> > OT, unrelated thing, in include/asan_interface.h there is one
>> > #if __has_feature(address_sanitizer)
>> > which for GCC should better be:
>> > #if (defined __has_f
On Fri, Feb 15, 2013 at 01:30:18PM +0400, Konstantin Serebryany wrote:
> > OT, unrelated thing, in include/asan_interface.h there is one
> > #if __has_feature(address_sanitizer)
> > which for GCC should better be:
> > #if (defined __has_feature && __has_feature(address_sanitizer)) \
> > || defi
On Fri, Feb 15, 2013 at 1:05 PM, Jakub Jelinek wrote:
> On Fri, Feb 15, 2013 at 12:47:30PM +0400, Konstantin Serebryany wrote:
>> This is ungood.
>> First, clang doesn't like it at all:
>> prelink1.cc:18:18: error: init_priority attribute requires integer
>> constant between 101 and 65535 inclusiv
On Fri, Feb 15, 2013 at 1:00 AM, Steven Bosscher wrote:
> Hello,
>
> A user sent me a request to give names to the digraph in a graph dump.
> This name can be used as a key for the dump, for a tool that can
> generate graph metrics to see GCC transforms code as it passes through
> the pipeline. An
On Fri, Feb 15, 2013 at 12:47:30PM +0400, Konstantin Serebryany wrote:
> This is ungood.
> First, clang doesn't like it at all:
> prelink1.cc:18:18: error: init_priority attribute requires integer
> constant between 101 and 65535 inclusive
> A __attribute__((init_priority (1))) a;
For gcc it is ju
On Thu, Feb 14, 2013 at 8:44 PM, Lawrence Crowl wrote:
> On 2/14/13, Richard Biener wrote:
>> On Tue, Feb 12, 2013 at 8:47 PM, Lawrence Crowl wrote:
>> > Add class record_builder to ease construction of records and unions. Use
>> > it
>> > in some appropriate places.
>
>> > tree
>> > -def
Ian, there is a question for you below.
On Fri, Feb 15, 2013 at 12:26 PM, Jakub Jelinek wrote:
> On Fri, Feb 15, 2013 at 11:45:15AM +0400, Konstantin Serebryany wrote:
>> On Thu, Feb 14, 2013 at 4:19 PM, Jakub Jelinek wrote:
>> > On Thu, Feb 14, 2013 at 03:55:47PM +0400, Konstantin Serebryany wr
On Fri, Feb 15, 2013 at 11:45:15AM +0400, Konstantin Serebryany wrote:
> On Thu, Feb 14, 2013 at 4:19 PM, Jakub Jelinek wrote:
> > On Thu, Feb 14, 2013 at 03:55:47PM +0400, Konstantin Serebryany wrote:
> >> The patch seems to work on a simple test. Let me digest it.
> >> I am trying to understand
44 matches
Mail list logo
