On Fri, 2013-10-18 at 00:34 -0400, David Edelsohn wrote:
> On Thu, Oct 17, 2013 at 10:43 PM, Bill Schmidt
> wrote:
> > Hi,
> >
> > In little endian mode, we managed to convert a load of the V4SI vector
> > {3, 3, 3, 7} into a vspltisw of 3, apparently taking offense at the
> > number 7. It turn
On Thu, Oct 17, 2013 at 10:43 PM, Bill Schmidt
wrote:
> Hi,
>
> In little endian mode, we managed to convert a load of the V4SI vector
> {3, 3, 3, 7} into a vspltisw of 3, apparently taking offense at the
> number 7. It turns out we only looked at the first N-1 elements of an
> N-element vector i
On Thu, Oct 17, 2013 at 8:54 PM, David Malcolm wrote:
>
> +* segfault seen in libbacktrace, when an ICE occurs
That reminded me to commit this libbacktrace patch I worked up a
couple of weeks ago. Previously if some debug section was missing,
the code could compute the wrong min_offset. The mis
On Thu, Oct 17, 2013 at 8:37 PM, Mike Stump wrote:
> On Oct 17, 2013, at 7:47 PM, Sriraman Tallam wrote:
>> I can build cross-compile on 32/33 targets. I cannot build
>> nios2-unknown-elf alone, I get "*** Configuration nios2-unknown-elf
>> not supported" error.
>
> nios2 is not a contributed por
I've committed this to dmalcolm/jit:
Replace various accessors to primitive types
(gcc_jit_context_get_char_type etc) with a single entrypoint
gcc_jit_context_get_type that takes an enum.
Add two other new entrypoints:
/* Floating-point constants. */
extern gcc_jit_rvalue *
gcc_jit_contex
I've committed this to dmalcolm/jit:
gcc/jit/
* libgccjit.h: Add and reword comments throughout.
---
gcc/jit/ChangeLog.jit | 4 ++
gcc/jit/libgccjit.h | 114 +-
2 files changed, 107 insertions(+), 11 deletions(-)
diff --git a/gcc/jit/Ch
I've committed this to dmalcolm/jit:
gcc/jit/
* TODO.rst: Update.
---
gcc/jit/ChangeLog.jit | 4 ++
gcc/jit/TODO.rst | 116 --
2 files changed, 117 insertions(+), 3 deletions(-)
diff --git a/gcc/jit/ChangeLog.jit b/gcc/jit/ChangeLog.
On Oct 17, 2013, at 7:47 PM, Sriraman Tallam wrote:
> I can build cross-compile on 32/33 targets. I cannot build
> nios2-unknown-elf alone, I get "*** Configuration nios2-unknown-elf
> not supported" error.
nios2 is not a contributed port yet on trunk.
> I have submitted this one line fix.
Or,
For cris-elf (no SIMD), the following tests regressed just as
for the similar tests mentioned in PR58556. These apparently
don't fail for the targets mentioned there for some reason, but
I see in the mail thread with the quoted subject there was no
conscious adjustment to the test-suite. Thus I b
On Thu, Oct 17, 2013 at 4:51 PM, Sriraman Tallam wrote:
> On Thu, Oct 17, 2013 at 3:08 PM, Sriraman Tallam wrote:
>> On Thu, Oct 17, 2013 at 1:23 PM, Mike Stump wrote:
>>> On Oct 17, 2013, at 10:23 AM, Sriraman Tallam wrote:
> You probably want to do something similar to what I did in the p
Here is a patch to correct the char type and the type, number of nontype
parameter pack for user defined strng literal operator templates.
Bootstrapped and tested on x86_64-linux.
OK?
gcc/cp:
2013-10-17 Edward Smith-Rowland <3dw...@verizon.net>
PR c++/58708
* parser.c (mak
Hi,
In little endian mode, we managed to convert a load of the V4SI vector
{3, 3, 3, 7} into a vspltisw of 3, apparently taking offense at the
number 7. It turns out we only looked at the first N-1 elements of an
N-element vector in little endian mode, and verified the zeroth element
twice. Adju
On Thu, Oct 17, 2013 at 4:18 PM, Vladimir Simonov
wrote:
>
> Thank you for pointing this problem.
>
> So, on file systems with symlinks support "playing" with filenames as strings
> is impossible.
> This means that filename_normalize name is too pretentious - it will do
> nothing for most of gcc
> "Andrew" == Andrew writes:
Andrew> +#ifdef HAVE_UNISTD_H
Andrew> + procs = sysconf(_SC_NPROCESSORS_ONLN);
Andrew> +#endif
Space before the "(".
Technically you should probably check for sysconf in configure.ac.
I'm not sure whether it matters any more.
I think _SC_NPROCESSORS_ONLN is n
On Thu, Oct 17, 2013 at 6:39 PM, Andrew Pinski wrote:
> On Thu, Oct 17, 2013 at 4:03 AM, Richard Biener
> wrote:
>> On Thu, Oct 17, 2013 at 4:14 AM, Andrew Pinski wrote:
>>> On Wed, Oct 16, 2013 at 2:12 AM, Zhenqiang Chen
>>> wrote:
Hi,
The patch enhances ifcombine pass to recove
On Thu, Oct 17, 2013 at 4:03 AM, Richard Biener
wrote:
> On Thu, Oct 17, 2013 at 4:14 AM, Andrew Pinski wrote:
>> On Wed, Oct 16, 2013 at 2:12 AM, Zhenqiang Chen
>> wrote:
>>> Hi,
>>>
>>> The patch enhances ifcombine pass to recover some non short circuit
>>> branches. Basically, it will do the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58669
Testing:
$ /usr/lib/jvm/icedtea-6/bin/java TestProcessors
Processors: 8
$ /usr/lib/jvm/gcj-jdk/bin/java -version
java version "1.5.0"
gij (GNU libgcj) version 4.8.1
$ /usr/lib/jvm/gcj-jdk/bin/java TestProcessors
Processors: 1
$ /home/andrew/buil
On Thu, Oct 17, 2013 at 8:46 PM, Paolo Carlini wrote:
>> + const wchar_t * s = L"ä½ å¥½, 世+ç•Œ";
>> + wregex re(s);
>> + VERIFY(regex_match_debug(L"ä½ å¥½, 世世世界", re));
Oops that's only perfect Chinese version of "hello, world" under UTF-8
charset. Now it's hex format.
I also make t
This patch finally renames tree-flow.h to tree-cfg.h. It now contains
just the prototypes for tree-cfg.h.
I've also removed all the #include's from tree-cfg.h, and relocated them
(temporarily) to tree-ssa.h which is acting as the tree-ssa module header.
tree-flow.h is removed from all includes
Hi,
On 10/18/2013 01:17 AM, Tim Shen wrote:
+ setlocale(LC_ALL, "zh_CN.UTF8");
+ const wchar_t * s = L"ä½ å¥½, 世+ç•Œ";
+ wregex re(s);
+ VERIFY(regex_match_debug(L"ä½ å¥½, 世世世界", re));
These strings make me a lot nervous: I should check the details of the
various character sets to
On Oct 17, 2013, at 4:51 PM, Sriraman Tallam wrote:
> I am running cross-compile builds on all the 33 failing targets. Like
> Mike said, it is only taking a few minutes per target. If there is no
> objection, I *will check in* this patch in another 2 hours provided
> all 33 targets succeed. This w
On Oct 17, 2013, at 1:46 AM, Richard Biener wrote:
> [This function shows another optimization issue:
>
>case BOOLEAN_TYPE:
> /* Cache false or true. */
> limit = 2;
> if (wi::leu_p (cst, 1))
>ix = cst.to_uhwi ();
>
> I would have expected cst <= 1 be optimized to cst
On Thu, Oct 17, 2013 at 3:08 PM, Sriraman Tallam wrote:
> On Thu, Oct 17, 2013 at 1:23 PM, Mike Stump wrote:
>> On Oct 17, 2013, at 10:23 AM, Sriraman Tallam wrote:
You probably want to do something similar to what I did in the powerpc.
>>>
>>> I would need the help of target maintainers to
The bug is because naively calling `map::count(__c)`
where __c could be a wchar_t, and an implicit cast(a truncate?)
happened.
-m32 and -m64 tested.
Thanks!
--
Tim Shen
a.patch
Description: Binary data
Hi,
On Thu, 2013-10-17 at 16:15 +0200, Christian Bruel wrote:
> Hello,
>
> This patch adds support to inline an optimized version of strcmp when
> not optimizing for size. The generated code makes use of the cmp/str
> instruction to test 4 bytes at a time when correctly aligned.
>
> note that a
Hi,
On Thu, 2013-10-17 at 16:13 +0200, Christian Bruel wrote:
> Hello,
>
> This patch just reorganizes the SH code used for memory builtins into
> its own file, in preparation of the RTL strcmp hoisting in the next part.
>
Since GCC is now being compiled as C++, it's probably better to name
new
On Thu, Oct 17, 2013 at 3:10 PM, Jakub Jelinek wrote:
> On Thu, Oct 17, 2013 at 12:30:46PM -0700, Sriraman Tallam wrote:
>> I checked my build again for these tests and they all pass.
>
> Even on x86_64-linux I can reproduce all of those with
> -m32 -mno-sse.
Ok, I never tested for no-sse. I wil
Hello!
>>> I would need the help of target maintainers to fix it this way since
>>> it touches every target and it would take time for me to build and
>>> test every target.
>>
>> For changes that only need a compile to ensure one didn't brake a port, a
>> configure and build of
> a target is 2 m
I've merged revision 203800 of the GCC 4.8 branch to the gccgo branch.
Ian
On Thu, Oct 17, 2013 at 12:30:46PM -0700, Sriraman Tallam wrote:
> I checked my build again for these tests and they all pass.
Even on x86_64-linux I can reproduce all of those with
-m32 -mno-sse.
Jakub
Mike Stump wrote:
>On Oct 17, 2013, at 6:14 AM, Richard Biener wrote:
>> These two patches try to fix handling of zero-precision integer
>> types (created by struct { int : 0; };).
>
>> Objections?
>
>In the wide-int branch we ran into :0 issues, and I think this patch
>likely eliminates that pro
On Thu, Oct 17, 2013 at 1:23 PM, Mike Stump wrote:
> On Oct 17, 2013, at 10:23 AM, Sriraman Tallam wrote:
>>> You probably want to do something similar to what I did in the powerpc.
>>
>> I would need the help of target maintainers to fix it this way since
>> it touches every target and it would
On 09/11/13 12:18, Iyer, Balaji V wrote:
Hello Everyone, Couple weeks back, I had submitted a patch for review
that will implement Cilk keywords (_Cilk_spawn and _Cilk_sync) into
the C compiler. I recently finished C++ implementation also. In this
email, I am attaching 2 patches: 1 for C (and the
Hi,
We have recently committed backports from trunk to linaro/gcc-4_8-branch:
203059,203116 (as 203137,203138)
201250 (as 203139)
202275 (as 203179)
202279 (as 203180)
202164 (as 203181)
201260,202400 (as 203183)
202023,202108
Committed on Charles' behalf as rev 203799 with this ChangeLog entry:
2013-10-17 Charles Bayis
* gcc.dg/builtin-apply2.c: Skip test on arm hardfloat ABI targets.
* gcc.dg/tls/pr42894.c: Remove dg-options for arm*-*-* targets.
* gcc.target/arm/thumb-ltu.c: Remove dg-skip-if and require
effective
On Thu, Oct 17, 2013 at 3:58 PM, Paolo Carlini wrote:
> Please explain in the ChangeLog *which* warnings.
Committed with attached patch.
Thanks!
--
Tim Shen
a.patch
Description: Binary data
I'm starting from an MCU that doesn't work right if GCC doesn't do
what the user tells GCC to do. I added -fstrict-volatile-bitfields to
tell gcc that it needs to be more strict than the standard allows for
bitfield access, because without that flag, there's no way to force
gcc to use a specific
On Thu, 17 Oct 2013, DJ Delorie wrote:
> > At least on ARM, you can e.g. have a non-bit-field "char" that occupies
> > part of the same 4-byte unit as an "int" bit-field.
>
> Ok, "when the user doesn't give the compiler conflicting requirements."
> (which is why I contemplated making those confl
On Oct 17, 2013, at 10:23 AM, Sriraman Tallam wrote:
>> You probably want to do something similar to what I did in the powerpc.
>
> I would need the help of target maintainers to fix it this way since
> it touches every target and it would take time for me to build and
> test every target.
For c
I found another bug in my recent change to fix the handling of imported
embedded builtin types. Two bugs means I need a different approach.
This patch removes the code I added earlier and adopts a simpler
approach, in which we mark a struct field for whether it is imported.
Bootstrapped and ran Go
On 10/17/2013 08:50 PM, Tim Shen wrote:
...to prevent potential bugs.
By the way, I execute `g++ -E file.cc > prep.cc && sed -i 's|^#.*$||'
prep.cc && g++ -Wall prep.cc 2> log` to get all warnings. Do we have a
better way?
Bootstraps and tested under -m64 and -m32.
Please explain in the Change
On Thu, Oct 17, 2013 at 12:30:46PM -0700, Sriraman Tallam wrote:
> I checked my build again for these tests and they all pass.
Perhaps it is the question of the default arch/tuning selection,
What do you get with ./cc1 -E -dD /dev/null | grep SSE in the 32-bit
cc1? Try compiling the testcases wit
On 10/17/13 04:41, Richard Biener wrote:
I don't see this as the major benefit of type demotion. Yes, there is some
value in shrinking constants and the like, but in my experience the benefits
are relatively small and often get lost in things like partial register
stalls on x86, the PA and proba
On Thu, Oct 17, 2013 at 12:08 PM, Sriraman Tallam wrote:
> On Thu, Oct 17, 2013 at 11:48 AM, Jakub Jelinek wrote:
>> On Thu, Oct 17, 2013 at 02:22:57PM -0400, Michael Meissner wrote:
>>> On Thu, Oct 17, 2013 at 10:23:27AM -0700, Sriraman Tallam wrote:
>>> > I would need the help of target maintai
On Oct 17, 2013, at 6:14 AM, Richard Biener wrote:
> These two patches try to fix handling of zero-precision integer
> types (created by struct { int : 0; };).
> Objections?
In the wide-int branch we ran into :0 issues, and I think this patch likely
eliminates that problem, so, I like it.
On Mon, Oct 14, 2013 at 08:59:50PM -0400, David Edelsohn wrote:
> Please use "VMX" instead of "AV", not because I am pedantic about
> IBM's name for the feature, but "AV" is meaningless to me and anyone
> else reading the code. If you need a three-letter name, use "VMX".
>
> Okay with that change.
The enclosed patch (which depends on
http://gcc.gnu.org/ml/gcc-patches/2013-10/msg01395.html), ports the
new -ggnu-pubnames option from google 4.8 to trunk.
-gnu-pubnames enable the gold linker to to generate a better
.gdb_index section by including various bits of data about the symbol.
OK for t
On Thu, Oct 17, 2013 at 11:48 AM, Jakub Jelinek wrote:
> On Thu, Oct 17, 2013 at 02:22:57PM -0400, Michael Meissner wrote:
>> On Thu, Oct 17, 2013 at 10:23:27AM -0700, Sriraman Tallam wrote:
>> > I would need the help of target maintainers to fix it this way since
>> > it touches every target and
On Thu, Oct 17, 2013 at 02:50:35PM -0400, Tim Shen wrote:
> ...to prevent potential bugs.
>
> By the way, I execute `g++ -E file.cc > prep.cc && sed -i 's|^#.*$||'
> prep.cc && g++ -Wall prep.cc 2> log` to get all warnings. Do we have a
> better way?
Sure, -Wsystem-headers -Wall.
Jakub
On Thu, 17 Oct 2013, Tim Shen wrote:
...to prevent potential bugs.
By the way, I execute `g++ -E file.cc > prep.cc && sed -i 's|^#.*$||'
prep.cc && g++ -Wall prep.cc 2> log` to get all warnings. Do we have a
better way?
-Wsystem-headers ?
(note also the -P flag)
--
Marc Glisse
On Thu, Oct 17, 2013 at 5:03 AM, Paolo Carlini wrote:
>> Though, in the above case, the question is why people ignore warnings from
>> the compiler and need to have special runtime instrumentation to remind them
>> instead. I'm not objecting to that sanitization, only find it weird.
That's my fau
The enclosed patch to "merge" gdb/gdb-index.h from the src/ tree to
gcc is in preparation for a patch to migrage -ggnu-pubnames from
gcc/google-4_8 to trunk. This later patch adds a flag-byte to pubnames
so that the gold linker can build a version 7 gdb index. This file is
already used by gdb and b
...to prevent potential bugs.
By the way, I execute `g++ -E file.cc > prep.cc && sed -i 's|^#.*$||'
prep.cc && g++ -Wall prep.cc 2> log` to get all warnings. Do we have a
better way?
Bootstraps and tested under -m64 and -m32.
Thanks!
--
Tim Shen
a.patch
Description: Binary data
On Thu, Oct 17, 2013 at 02:22:57PM -0400, Michael Meissner wrote:
> On Thu, Oct 17, 2013 at 10:23:27AM -0700, Sriraman Tallam wrote:
> > I would need the help of target maintainers to fix it this way since
> > it touches every target and it would take time for me to build and
> > test every target.
This patch to libgo adds some system calls to the syscall package.
Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
Committed to mainline and 4.8 branch, since these calls were in Go
1.1.2.
Ian
diff -r 1fab07e328de libgo/configure.ac
--- a/libgo/configure.ac Thu Oct 17 08:41:31 2013
On Thu, 2013-10-17 11:06:44 -0700, Xinliang David Li wrote:
> JBG, Steve, Can you help testing Sri's latest patch on your targets?
> This will help speed up the process.
The one-line revert will probably "fix" all of those. Though it's
open to discussion if we want to do that, or forward-port al
On Thu, Oct 17, 2013 at 11:25 AM, Jan-Benedict Glaw wrote:
> On Thu, 2013-10-17 11:06:44 -0700, Xinliang David Li
> wrote:
>> JBG, Steve, Can you help testing Sri's latest patch on your targets?
>> This will help speed up the process.
>
> The one-line revert will probably "fix" all of those. Th
On Thu, Oct 17, 2013 at 10:23:27AM -0700, Sriraman Tallam wrote:
> I would need the help of target maintainers to fix it this way since
> it touches every target and it would take time for me to build and
> test every target.
>
> Michael, OTOH, I dont see any other targets other than i386 and rs60
Ping?
thanks,
Cong
On Mon, Oct 7, 2013 at 10:15 AM, Cong Hou wrote:
> You are right. I am not an expert on numerical analysis, but I tested
> your case and it proves the number 4 conversion is not safe.
>
> Now we have four conversions which are safe once the precision
> requirement is satisfi
On Thu, 2013-10-17 at 11:06 -0700, Xinliang David Li wrote:
> JBG, Steve, Can you help testing Sri's latest patch on your targets?
> This will help speed up the process.
>
> thanks,
>
> David
I have already tested the one line patch to opth-gen.awk. It fixes the
MIPS build and a testsuite run l
JBG, Steve, Can you help testing Sri's latest patch on your targets?
This will help speed up the process.
thanks,
David
On Thu, Oct 17, 2013 at 10:49 AM, Jan-Benedict Glaw wrote:
> On Thu, 2013-10-17 10:23:27 -0700, Sriraman Tallam
> wrote:
> [...]
>> I would need the help of target maintaine
On Thu, Oct 17, 2013 at 10:49 AM, Jan-Benedict Glaw wrote:
> On Thu, 2013-10-17 10:23:27 -0700, Sriraman Tallam
> wrote:
> [...]
>> I would need the help of target maintainers to fix it this way since
>> it touches every target and it would take time for me to build and
>> test every target.
>
>
On Thu, 2013-10-17 10:23:27 -0700, Sriraman Tallam wrote:
[...]
> I would need the help of target maintainers to fix it this way since
> it touches every target and it would take time for me to build and
> test every target.
Then you should have probably waited some time, mark your patch as RFC
u
Hello!
The isa attribute is not needed since we already constrainted insn
with TARGET_AVX2.
2013-10-17 Uros Bizjak
* config/i386/sse.md (*vec_widen_smult_even_v8si): Remove
isa attribute.
Tested on x86_64-pc-linux-gnu {,-m32} and committed to mainline SVN.
Uros.
Index: config/i386/s
Hello!
Attached patch improves ix86_fixup_binary_operands a bit for the
unlikely situation when both input operands are placed in memory. The
patch forces non-matched operand 1 into register, leaving operand 2 in
memory. Since x86 instruction patterns allow memory operand via
operand 2, the new ap
> At least on ARM, you can e.g. have a non-bit-field "char" that occupies
> part of the same 4-byte unit as an "int" bit-field.
Ok, "when the user doesn't give the compiler conflicting requirements."
(which is why I contemplated making those conflicts errors at first)
I'm a big fan of blaming t
I tested this case with -fno-tree-loop-im and -fno-tree-pre, and it
seems that GCC could hoist j+1 outside of the i loop:
t3.c:5:5: note: hoisting out of the vectorized loop: _10 = (sizetype) j_25;
t3.c:5:5: note: hoisting out of the vectorized loop: _11 = _10 + 1;
t3.c:5:5: note: hoisting out of
On Thu, Oct 17, 2013 at 9:52 AM, Michael Meissner
wrote:
> On Thu, Oct 17, 2013 at 09:28:26AM -0700, Steve Ellcey wrote:
>> On Thu, 2013-10-17 at 06:03 -0700, Diego Novillo wrote:
>> > On Wed, Oct 16, 2013 at 6:06 PM, David Edelsohn wrote:
>> >
>> > > How is Google going to change its patch commi
On Thu, 17 Oct 2013, DJ Delorie wrote:
> > It is as Sandra said, at least on ARM -fstrict-volatile-bitfields
> > does not function at all. And the C++11 memory model wins all the time.
>
> Are we talking about N2429? I read through the changes and it didn't
> preclude honoring the user's types.
On Mon, Oct 14, 2013 at 08:51:15PM -0400, David Edelsohn wrote:
> > [gcc]
> > 2013-10-11 Michael Meissner
> >
> > PR target/58673
> > * config/rs6000/rs6000.c (rs6000_legitimate_address_p): Only
> > restrict TImode addresses to single indirect registers if both
> >
Hi all,
This patch adds the rtx costs table for the Cortex-A9 core.
An arm-none-eabi regression run tuned for A9 succeeded.
This costs tabled showed a slight improvement on some popular benchmarks and no
performance regressions on others against the old way of doing rtx costs.
Ok for trunk?
T
On Thu, Oct 17, 2013 at 06:47:10PM +0200, Bernd Edlinger wrote:
> 2013-10-17 Bernd Edlinger
>
> PR libmudflap/58230
> * testsuite/lib/mfdg.exp: Set C Language.
s/Set C Language/Use C locale/.
Ok with that change.
Jakub
On 10/17/13 05:03, Richard Biener wrote:
Is it OK for trunk?
I had a much simpler change which did basically the same from 4.7 (I
can update it if people think this is a better approach).
I like that more (note you can now use is_gimple_condexpr as predicate
for force_gimple_operand).
The obv
On 10/17/2013 10:05 AM, Richard Sandiford wrote:
Richard Biener writes:
What's the reason again to not use my original proposed encoding
of the MSB being the sign bit? RTL constants simply are all signed
then. Just you have to also sign-extend in functions like lts_p
as not all constants are
On Thu, Oct 17, 2013 at 09:28:26AM -0700, Steve Ellcey wrote:
> On Thu, 2013-10-17 at 06:03 -0700, Diego Novillo wrote:
> > On Wed, Oct 16, 2013 at 6:06 PM, David Edelsohn wrote:
> >
> > > How is Google going to change its patch commit policies to ensure that
> > > this does not happen again?
> >
On 10/17/2013 09:48 AM, Richard Biener wrote:
On Thu, 17 Oct 2013, Richard Sandiford wrote:
Richard Biener writes:
On Thu, 17 Oct 2013, Richard Sandiford wrote:
Richard Biener writes:
The new tree representation can have a length greater than max_len
for an unsigned tree constant that occ
Hello,
this is a simple test that makes the follwing test cases pass:
because the messages are translated to german,
which the test scripts compare against english messages.
Tested on german ubuntu 12.04.
OK for trunk?
Regards
Bernd.2013-10-17 Bernd Edlinger
On 17 October 2013 17:27, James Greenhalgh wrote:
>
> Hi,
>
> I spotted that the types of arguments to these intrinsics are wrong,
> which results in all sorts of fun issues!
>
> Fixed thusly, regression tested with aarch64.exp on aarch64-none-elf
> with no issues.
>
> OK?
>
> Thanks,
> James
>
>
On 17 October 2013 12:13, Kyrill Tkachov wrote:
> [gcc/]
> 2013-10-17 Kyrylo Tkachov
>
> * config/aarch64/aarch64.c (aarch64_print_operand): Handle 'c'.
>
> [gcc/testsuite]
> 2013-10-17 Kyrylo Tkachov
>
> * gcc.target/aarch64/c-output-template.c: New testcase.
> * gcc.target/aar
Hi,
This patch addresses an issue in reload triggered by the
gfortran.dg/loc_2.f90 regression test at -O3 with LRA disabled.
The patch is based on work done by Ian Bolton here at ARM which I've
dusted down and submitted.
Following SFP elimination and under heavy register pressure, reload
attemp
OK.
Jason
On Thu, Oct 17, 2013 at 9:28 AM, Steve Ellcey wrote:
> On Thu, 2013-10-17 at 06:03 -0700, Diego Novillo wrote:
>> On Wed, Oct 16, 2013 at 6:06 PM, David Edelsohn wrote:
>>
>> > How is Google going to change its patch commit policies to ensure that
>> > this does not happen again?
>>
>> There is n
On Thu, 2013-10-17 at 06:03 -0700, Diego Novillo wrote:
> On Wed, Oct 16, 2013 at 6:06 PM, David Edelsohn wrote:
>
> > How is Google going to change its patch commit policies to ensure that
> > this does not happen again?
>
> There is nothing to change. Google follows
> http://gcc.gnu.org/contr
Hi,
I spotted that the types of arguments to these intrinsics are wrong,
which results in all sorts of fun issues!
Fixed thusly, regression tested with aarch64.exp on aarch64-none-elf
with no issues.
OK?
Thanks,
James
---
2013-10-17 James Greenhalgh
* config/aarch64/arm_neon.h
Hi,
in this ICE on valid, 4.8/4.9 Regression, the problem is that, for a
lambda in an NSDMI context, the early return of lambda_expr_this_capture:
/* In unevaluated context this isn't an odr-use, so just return the
nearest 'this'. */
if (cp_unevaluated_operand)
return lookup_
On Thu, Oct 17, 2013 at 12:35 AM, Marek Polacek wrote:
> On Wed, Oct 16, 2013 at 04:25:58PM -0700, Wei Mi wrote:
>> +/* Return true if target platform supports macro-fusion. */
>> +
>> +static bool
>> +ix86_macro_fusion_p ()
>> +{
>> + if (TARGET_FUSE_CMP_AND_BRANCH)
>> +return true;
>> + e
On 17 October 2013 10:43, Michael Hudson-Doyle
wrote:
> Resending as the previous attempt went missing...
>
> 2013-10-04 Michael Hudson-Doyle
>
> * libatomic/configure.tgt (aarch64*): Remove code preventing
> build.
>
> * gcc/testsuite/lib/target-supports
> where in the C standard did you read the requirement that every bit
> field must be complete? (This is a serious question).
The spec doesn't say each field must be complete, but neither does it
say that the structure must be as big as the type used. If you
specify "int foo:1" then the compile
On 10/17/2013 11:15 AM, Jakub Jelinek wrote:
*** struct omp_for_data
*** 135,141
static splay_tree all_contexts;
static int taskreg_nesting_level;
static int target_nesting_level;
! struct omp_region *root_omp_region;
static bitmap task_shared_vars;
static void
I've merged revision 203772 from the GCC 4.8 branch to the gccgo branch.
Ian
On Thu, Oct 17, 2013 at 11:52:21AM -0400, Andrew MacLeod wrote:
> On 10/17/2013 11:15 AM, Jakub Jelinek wrote:
> >>*** struct omp_for_data
> >>*** 135,141
> >> static splay_tree all_contexts;
> >> static int taskreg_nesting_level;
> >> static int target_nesting_level;
> >>! s
This patch fixes the Go frontend to not dereference an unknown type when
importing an anonymous field. This fixes a bug in a recent patch I
committed. I have a test case ready to commit to the master repository
after the Go 1.2 release is made. This patch bootstrapped and ran Go
testsuite on x86
On 10/15/2013 05:21 PM, Adam Butcher wrote:
On Wed, 25 Sep 2013 11:01:26 -0500, Jason Merrill wrote:
1) Build up the type as normal and use tsubst to replace the non-pack
template parameter with a pack if needed.
The problem I've hit with this (and other hacks I've tried that involve
finishing
On Tue, Oct 15, 2013 at 10:46:43PM -0400, Andrew MacLeod wrote:
> Bootstraps on 86_64-unknown-linux-gnu and no new regressions. OK?
>
> Andrew
>
> * tree-flow.h (struct omp_region): Move to omp-low.c
Missing dot at the end of line.
> Remove omp_ prototypes and variables.
> *
On Thu, Oct 17, 2013 at 11:26:56AM +0200, Richard Biener wrote:
> On Wed, 16 Oct 2013, pins...@gmail.com wrote:
>
> >
> > > On Oct 15, 2013, at 5:32 AM, Jakub Jelinek wrote:
> > > Especially on i?86/x86_64 if-conversion pass seems to be often
> > > a pessimization, but the vectorization relies o
On 10/17/2013 09:16 AM, Richard Biener wrote:
On Thu, 17 Oct 2013, Kenneth Zadeck wrote:
On 10/17/2013 08:29 AM, Richard Biener wrote:
On Thu, 17 Oct 2013, Richard Sandiford wrote:
Richard Biener writes:
The new tree representation can have a length greater than max_len
for an unsigned tre
Richard Biener writes:
> What I see is really bad code for the simple integer-cst predicates
> in tree.c. I don't mind in what way we fix it, but avoiding the
> copy on every tree integer constant read looks required to me.
But we got rid of the copy with yesterday's patch. Are you talking
abou
On 07/14/2013 09:54 AM, Chung-Lin Tang wrote:
> These are nios2 patches for the gcc testsuite. Some new testcases were
> added since the last posting.
> Index: gcc/testsuite/gcc.c-torture/execute/builtins/lib/chk.c
> ===
> --- gcc/tes
On Thu, 17 Oct 2013, Richard Sandiford wrote:
> Richard Biener writes:
> >> > What's the reason again to not use my original proposed encoding
> >> > of the MSB being the sign bit? RTL constants simply are all signed
> >> > then. Just you have to also sign-extend in functions like lts_p
> >> >
Hello,
On 17 Oct 13:14, Uros Bizjak wrote:
> On Thu, Oct 17, 2013 at 12:47 PM, Kirill Yukhin
> wrote:
> >
> >> > I suspect gen_lowpart is bad turn when reload is completed, as
> >> > far as it can create new pseudo. gen_lowpart () may call
> >> > gen_reg_rtx (), which contain corresponging gcc_as
1 - 100 of 168 matches
Mail list logo
