Hi Kyrill,
> 2016-01-22 Kyrylo Tkachov
>
> * config/arm/arm.c (arm_new_rtx_costs, MULT case): Properly extract
> the operands of the SIGN_EXTENDs from a SMUL[TB][TB] rtx.
Approved - please apply.
Cheers
Nick
Hi Kyrill,
I would like to approve this patch, but cannot, since it is not ARM
specific. I think that if you ping the list you may be able to get a
response, and it would be nice to see this whole patch series checked
in before the gcc 6 branch occurs.
Cheers
Nick
PS. If necessary yo
> 2016-01-22 Kyrylo Tkachov
>
> * gcc.target/arm/wmul-3.c: Simplify test to generate just
> a single smulbb instruction.
> * gcc.target/amr/wmul-1.c: Add -mtune=cortex-a9 to dg-options.
> * gcc.target/amr/wmul-2.c: Likewise.
Approved - please apply.
Cheers
Nick
> Can you explain why the GCC internals cause us to get SCmode instead of
> BLKmode for the example with _Complex? I don't understand that. It
> seems wrong to me and I don't understand where it is coming from.
compute_record_mode uses BLKmode only as a last resort because this will
significant
Am 02.02.2016 um 21:26 schrieb Janus Weil:
Hi all,
here is a diagnostics patch, which makes sure that the responsible
flag is printed in several warning messages (for which this was still
missing).
The only case that I'm not completely sure about is the hunk in
intrinsic.c. In particular I was
Hi Sandra,
Thanks for your feedback.
On 02/02/2016 08:57 PM, Sandra Loosemore wrote:
> On 02/02/2016 02:06 AM, mickael guene wrote:
>> Hi All,
>>
>>Ping for following thread :
>>
>> https://gcc.gnu.org/ml/gcc-patches/2016-01/msg01968.html
>> https://gcc.gnu.org/ml/gcc-patches/2016-01/msg019
Hi Nick,
On 03/02/16 08:35, Nick Clifton wrote:
Hi Kyrill,
I would like to approve this patch, but cannot, since it is not ARM
specific. I think that if you ping the list you may be able to get a
response, and it would be nice to see this whole patch series checked
in before the gc
On Wed, Feb 03, 2016 at 09:46:31AM +, Kyrill Tkachov wrote:
> Hi Nick,
>
> On 03/02/16 08:35, Nick Clifton wrote:
> >Hi Kyrill,
> >
> > I would like to approve this patch, but cannot, since it is not ARM
> > specific. I think that if you ping the list you may be able to get a
> > respon
On Thu, Jan 28, 2016 at 02:33:20PM +, James Greenhalgh wrote:
> On Mon, Jan 25, 2016 at 08:09:39PM +, Wilco Dijkstra wrote:
> > Andreas Schwab wrote:
> >
> > > FAIL: gcc.target/aarch64/ccmp_1.c scan-assembler-times \tcmp\tw[0-9]+, 0 4
> > > FAIL: gcc.target/aarch64/ccmp_1.c scan-assembler
On 03/02/16 09:51, Jakub Jelinek wrote:
On Wed, Feb 03, 2016 at 09:46:31AM +, Kyrill Tkachov wrote:
Hi Nick,
On 03/02/16 08:35, Nick Clifton wrote:
Hi Kyrill,
I would like to approve this patch, but cannot, since it is not ARM
specific. I think that if you ping the list you may be
Hi Paul,
thanks for the review. Committed as:
r233099 for ggc-5, and
r233101 for trunk.
Regards,
Andre
On Tue, 2 Feb 2016 19:44:00 +0100
Paul Richard Thomas wrote:
> Hi Andre,
>
> This one looks good too. As every day goes by, I see more and more why
> Tobias was so keen to incorpo
On 26/01/16 12:23, Dominik Vogt wrote:
On Mon, Dec 21, 2015 at 01:13:28PM +, Alan Lawrence wrote:
...the test passes with --param sra-max-scalarization-size-Ospeed.
Verified on aarch64 and with stage1 compiler for hppa, powerpc, sparc, s390.
How did you test this on s390? For me, the tes
James Greenhalgh wrote:
> I'm still seeing:
>
> FAIL: gcc.target/aarch64/ccmp_1.c scan-assembler-times \\tcmp\\tw[0-9]+,
> (0|wzr) 4
That's because "(0|wzr)" is not correctly matching due to the weird regular
expression syntax used in the testsuite (I tried with several escapes to no
avail). I
Fix the ccmp_1.c test back to use '0' as regular expressions don't work
correctly. '0' is right due to compare with zero now printing as 'CMP w0, 0'
rather than 'CMP w0, wzr' (since r232921).
Committed as trivial patch in r233102.
ChangeLog:
2016-02-03 Wilco Dijkstra
gcc/testsuite/
Dear Mikael,
The patch is OK for trunk.
A small niggle: Although present in the original testcase, 'a' is unused.
I am not in a position to find out for myself, right now, but does the
testcase of comment #10 work with this patch?
Thanks for the patch
Paul
On 1 February 2016 at 23:07, Mikael
On February 3, 2016 8:11:01 AM GMT+01:00, Richard Henderson
wrote:
>On 02/03/2016 06:05 PM, Richard Biener wrote:
> I wasn't aware that STRIP_NOPS strips ADDR_SPACE_CONVERT_EXPR.
>>
>> Isn't this maybe failing to use that (unable to look at the
>attachment from my phone).
>
>The test case does f
Hello,
As proposed in PR69118 - fixed condition of compare pattern.
Bootstrapped, regtested & comitted to main trunk & gcc-5-branch.
gcc/
PR target/69118
* config/i386/sse.md (define_insn "avx512f_maskcmp3"):
Fix target.
--
Thanks, K
commit 7fa978b9b80a6d50a81065755be81a
Hello!
Attached patch improves detection of working -fsanitize=thread option.
Check for working -fsanitize=thread option timeouts with older glibcs,
so tsan_init detects this case and sets default compile flags to
compile.
Recently Eric changed check_effective_target_fsanitize_thread to a
runtime
On Wed, Feb 03, 2016 at 02:53:56PM +0100, Uros Bizjak wrote:
> diff --git a/gcc/testsuite/lib/asan-dg.exp b/gcc/testsuite/lib/asan-dg.exp
> index 994160e..a1198c0 100644
> --- a/gcc/testsuite/lib/asan-dg.exp
> +++ b/gcc/testsuite/lib/asan-dg.exp
> @@ -20,7 +20,7 @@
> proc check_effective_target_fs
On Wed, Feb 3, 2016 at 2:59 PM, Jakub Jelinek wrote:
> On Wed, Feb 03, 2016 at 02:53:56PM +0100, Uros Bizjak wrote:
>> diff --git a/gcc/testsuite/lib/asan-dg.exp b/gcc/testsuite/lib/asan-dg.exp
>> index 994160e..a1198c0 100644
>> --- a/gcc/testsuite/lib/asan-dg.exp
>> +++ b/gcc/testsuite/lib/asan-
Hi!
As mentioned in the PR, the expander now requires that calls with
TREE_ADDRESSABLE result type have lhs set (so that a temporary of the
type doesn't have to be created by the middle-end).
The first 3 hunks (gimplify.c and cgraphunit.c) are to fix noreturn
functions with such return types, by
On Wed, Feb 03, 2016 at 03:12:27PM +0100, Uros Bizjak wrote:
> On Wed, Feb 3, 2016 at 2:59 PM, Jakub Jelinek wrote:
> > On Wed, Feb 03, 2016 at 02:53:56PM +0100, Uros Bizjak wrote:
> >> diff --git a/gcc/testsuite/lib/asan-dg.exp b/gcc/testsuite/lib/asan-dg.exp
> >> index 994160e..a1198c0 100644
>
I've backported this patch from trunk to gomp-4_0-branch. This patch
updates a previous patch to gomp4 in dealing with variables used
within a routine procedure.
Reference:
https://gcc.gnu.org/ml/gcc-patches/2016-01/msg01231.html
Thanks,
Jim
ChangeLog entries...
gcc/
> Attached patch improves detection of working -fsanitize=thread option.
> Check for working -fsanitize=thread option timeouts with older glibcs,
> so tsan_init detects this case and sets default compile flags to
> compile.
>
> Recently Eric changed check_effective_target_fsanitize_thread to a
> r
On 19/01/16 16:45 +0100, Jan Hubicka wrote:
Index: changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-6/changes.html,v
retrieving revision 1.46
diff -u -r1.46 changes.html
--- changes.html22 Dec 2015 19:23:31 - 1
First, I will split this patch in two. The first part will deal with the FPU
instructions. The second patch, will try to address a new abi optimized for
odd-even registers as the comments for the mabi=optimized are numerous and I
need to carefully prepare for an answer.
The remaining of this ema
Jakub,
this is the runtime side of default compute dimension support.
1) extend the -fopenacc-dim=X:Y:Z syntax to allow '-' indicating a runtime
choice. (0 also indicates that, but I thought best to have an explicit syntax
as well).
2) New plugin helper 'GOMP_PLUGIN_acc_default_dims' that pa
On 01/29/2016 01:30 PM, Jakub Jelinek wrote:
On Fri, Jan 29, 2016 at 11:35:07AM +0100, Jakub Jelinek wrote:
I can try to stick there an assert whether for FUNCTION_DECL
(DECL_INITIAL (decl) == 0) == DECL_EXTERNAL (decl).
Tried that, but cancelled that quickly, I see lots of cases where
DECL_IN
OK.
Jason
OK.
Jason
On 11/09/2015 04:30 AM, Patrick Palka wrote:
+ if (complain & tf_warning)
+ {
+ if (VAR_P (old_expr))
+ warning (0, "dynamic_cast of %q#D to %q#T can never
succeed",
+ old_expr, type);
+ els
Hello,
On Wed, 3 Feb 2016, Nathan Sidwell wrote:
> 1) extend the -fopenacc-dim=X:Y:Z syntax to allow '-' indicating a runtime
> choice. (0 also indicates that, but I thought best to have an explicit syntax
> as well).
Does it work when the user specifies one of the dimensions, so that references
On 02/03/16 11:10, Alexander Monakov wrote:
Hello,
On Wed, 3 Feb 2016, Nathan Sidwell wrote:
1) extend the -fopenacc-dim=X:Y:Z syntax to allow '-' indicating a runtime
choice. (0 also indicates that, but I thought best to have an explicit syntax
as well).
Does it work when the user specifies
On 12/22/2015 12:07 AM, Patrick Palka wrote:
+ if (code == EQ_EXPR || code == NE_EXPR)
+{
+ if (TREE_CODE (lhs) == PTRMEM_CST && CONSTANT_CLASS_P (rhs))
+ lhs = cplus_expand_constant (lhs);
+ if (TREE_CODE (rhs) == PTRMEM_CST && CONSTANT_CLASS_P (lhs))
+ rhs = cplus_exp
This patch fixes an exponential issue in ccmp.c. When deciding which ccmp
expansion to use, the tree nodes gs0 and gs1 are fully expanded twice. If
they contain more CCMP opportunities, their subtrees are also expanded twice.
When the trees are complex the expansion takes exponential time and mem
On Wed, 3 Feb 2016, Nathan Sidwell wrote:
> You can only override at runtime those dimensions that you said you'd override
> at runtime when you compiled your program.
Ah, I see. That's not obvious to me, so perhaps added documentation can be
expanded to explain that? (I now see that the plugin
Marcin KoÅcielnicki wrote:
> Comment fixed, split_stack_marker gone, reorg gone. Generated code seems
> sane,
> but testsuite still running.
>
> I will need to modify the gold patch to handle the "leaf function taking
> non-split
> stack function address" issue - this will likely require mess
On 02/02/2016 09:59 AM, Jakub Jelinek wrote:
I wonder if it wouldn't be better to pass around some structure, containing
for the common case fixed size cache and perhaps fall back to hash_map if
there are more calls to cache than that. Plus perhaps a recursion depth, so
that we avoid other path
On Wed, Feb 03, 2016 at 06:07:25PM +0100, Bernd Schmidt wrote:
> On 02/02/2016 09:59 AM, Jakub Jelinek wrote:
>
> >I wonder if it wouldn't be better to pass around some structure, containing
> >for the common case fixed size cache and perhaps fall back to hash_map if
> >there are more calls to cac
On Tue, 2016-02-02 at 20:36 +, Jonathan Wakely wrote:
I had some difficulty reading the new section; mostly due to the
leapfrogging of C++11 by the default (my immediate reaction was "why is
it talking about C++11 when the option says GNU++14?")
I'm attaching a patch which I hope clarifies it
libgcc/ChangeLog:
* config.host: Use t-stack and t-stack-s390 for s390*-*-linux.
* config/s390/morestack.S: New file.
* config/s390/t-stack-s390: New file.
* generic-morestack.c (__splitstack_find): Add s390-specific code.
gcc/ChangeLog:
* common/config/s3
Le 03/02/2016 14:00, Paul Richard Thomas a écrit :
Dear Mikael,
The patch is OK for trunk.
A small niggle: Although present in the original testcase, 'a' is unused.
Indeed, I'll remove it.
I am not in a position to find out for myself, right now, but does the
testcase of comment #10 work wi
Marcin KoÅcielnicki wrote:
> libgcc/ChangeLog:
>
> * config.host: Use t-stack and t-stack-s390 for s390*-*-linux.
> * config/s390/morestack.S: New file.
> * config/s390/t-stack-s390: New file.
> * generic-morestack.c (__splitstack_find): Add s390-specific code.
>
> gcc/C
On Tue, 2 Feb 2016, Jason Merrill wrote:
On 12/22/2015 12:07 AM, Patrick Palka wrote:
+ if (code == EQ_EXPR || code == NE_EXPR)
+{
+ if (TREE_CODE (lhs) == PTRMEM_CST && CONSTANT_CLASS_P (rhs))
+ lhs = cplus_expand_constant (lhs);
+ if (TREE_CODE (rhs) == PTRMEM_CST && CONS
On 03/02/16 12:13 -0500, David Malcolm wrote:
On Tue, 2016-02-02 at 20:36 +, Jonathan Wakely wrote:
I had some difficulty reading the new section; mostly due to the
leapfrogging of C++11 by the default (my immediate reaction was "why is
it talking about C++11 when the option says GNU++14?")
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69461
The patch actually solves several issues. Before the patch LRA has
>800 more failures on GCC testsuite on power8. After the patch the LRA
has the same number of failures as reload.
Working on the patch, I thin
Hi,
2016-02-03 10:21 GMT+01:00 Manfred Schwarb :
>> here is a diagnostics patch, which makes sure that the responsible
>> flag is printed in several warning messages (for which this was still
>> missing).
>>
>
>if (source_size < result_size)
> -gfc_warning (0, "Intrinsic TRANSFER at %L has
On Tue, 2 Feb 2016, Jason Merrill wrote:
On 11/09/2015 04:30 AM, Patrick Palka wrote:
+ if (complain & tf_warning)
+ {
+ if (VAR_P (old_expr))
+ warning (0, "dynamic_cast of %q#D to %q#T can never
succeed",
+
The second issue I'm still not sure about is the magic nop marker
for frameless functions. In an earlier mail you wrote:
Both currently supported
architectures always emit split-stack code on every function.
At least for rs6000 this doesn't appear to be true; in
rs6000_expand_split_stack_p
On 03/02/16 15:02, Claudiu Zissulescu wrote:
First, I will split this patch in two. The first part will deal with the FPU
instructions. The second patch, will try to address a new abi optimized for
odd-even registers as the comments for the mabi=optimized are numerous and I
need to carefully
On Feb 3, 2016, at 9:13 AM, David Malcolm wrote:
>> +pointer constants, so other constants such as false and
>> +(1 - 1) cannot be used where a null pointer is desired.
So, I’d leave this out entirely. The subject is porting, not the fine detail
pedanticism only a language lawyer could love. W
On 02/02/2016 08:21 PM, Martin Sebor wrote:
On 02/02/2016 05:28 AM, Jason Merrill wrote:
On 01/25/2016 05:55 PM, Martin Sebor wrote:
The downside of this approach is that it prevents everything but
the front end from distinguishing flexible array members from
arrays of unspecified or unknown bo
On Wed, Feb 03, 2016 at 10:42:37AM -0800, Mike Stump wrote:
> On Feb 3, 2016, at 9:13 AM, David Malcolm wrote:
> >> +pointer constants, so other constants such as false and
> >> +(1 - 1) cannot be used where a null pointer is desired.
>
> So, I’d leave this out entirely. The subject is porting,
OK.
Jason
From: Charles Baylis
This is an updated patch, which fixes the following issues:
. big endian ICE with vshuf-* tests
. style issues reported by check_GNU_style.sh
This has no regressions with -mfpu=neon, for arm-unknown-linux-gnueabihf and
armeb-unknown-linux-gnueabihf. The new test passes for b
From: Charles Baylis
gcc/ChangeLog:
2016-02-03 Charles Baylis
PR target/68532
* config/arm/arm.c (arm_evpc_neon_vzip): Allow for big endian lane
order.
* config/arm/arm_neon.h (vzipq_s8): Adjust shuffle patterns for big
endian.
(vzipq_s16): Lik
From: Charles Baylis
gcc/ChangeLog:
2016-02-03 Charles Baylis
PR target/68532
* config/arm/arm.c (neon_endian_lane_map): New function.
(neon_vector_pair_endian_lane_map): New function.
(arm_evpc_neon_vuzp): Allow for big endian lane order.
* config/arm
On Feb 2, 2016, at 10:29 PM, Sebastian Huber
wrote:
> If it is so basic to choose the latest release or the one on the system, then
> why uses the contrib/download_prerequisites ancient versions, e.g. the six
> year old GMP 4.3.2?
Because no one has seen fit to update it? I’ll plead ignorance
On 01/08/16 16:55, Evandro Menezes wrote:
On 12/16/2015 02:11 PM, Evandro Menezes wrote:
On 12/16/2015 05:24 AM, Richard Earnshaw (lists) wrote:
On 15/12/15 23:34, Evandro Menezes wrote:
On 12/14/2015 05:26 AM, James Greenhalgh wrote:
On Thu, Dec 03, 2015 at 03:07:43PM -0600, Evandro Menezes
On 01/21/16 16:55, Evandro Menezes wrote:
On 01/21/16 16:07, James Greenhalgh wrote:
On Thu, Jan 21, 2016 at 01:58:31PM -0600, Evandro Menezes wrote:
Hi, James.
On 01/21/16 03:24, James Greenhalgh wrote:
On Wed, Jan 06, 2016 at 02:44:47PM -0600, Evandro Menezes wrote:
On 01/06/2016 06:04 AM,
Hi!
If we report error from cpp_interpret_charconst (or functions it calls),
we leave *pchars_seen and *unsignedp uninitialized, and as the return
value for error (0) is also valid return value for valid programs,
various callers look at the uninitialized variables.
Fixed thusly, bootstrapped/reg
Hi!
As range->m_caret.m_{line,column} is only initialized if
range->m_show_caret_p is true, we really shouldn't be looking at those
fields otherwise.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?
2016-02-03 Jakub Jelinek
PR c/69627
* diagno
Hi!
On Tue, Feb 02, 2016 at 05:09:34PM +0300, Ilya Enkovich wrote:
> And it's too late to do it after STV pass and therefore we disable it
> when stack is not properly aligned. I think this argumentation goes in
> a loop.
This is a P1 that needs to be fixed, so that we don't defer this forever,
w
On Wed, 2016-02-03 at 21:07 +0100, Jakub Jelinek wrote:
> Hi!
>
> As range->m_caret.m_{line,column} is only initialized if
> range->m_show_caret_p is true, we really shouldn't be looking at
> those
> fields otherwise.
> Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
> ok for
On 02/04/2016 12:46 AM, Richard Biener wrote:
On February 3, 2016 8:11:01 AM GMT+01:00, Richard Henderson
wrote:
On 02/03/2016 06:05 PM, Richard Biener wrote:
I wasn't aware that STRIP_NOPS strips ADDR_SPACE_CONVERT_EXPR.
Isn't this maybe failing to use that (unable to look at the
attachm
On 02/03/2016 01:25 PM, David Malcolm wrote:
On Wed, 2016-02-03 at 21:07 +0100, Jakub Jelinek wrote:
Hi!
As range->m_caret.m_{line,column} is only initialized if
range->m_show_caret_p is true, we really shouldn't be looking at
those
fields otherwise.
Fixed thusly, bootstrapped/regtested on x86_
On Wed, Feb 03, 2016 at 01:02:57PM -0500, Vladimir Makarov wrote:
> The following patch fixes
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69461
>
> The patch actually solves several issues. Before the patch LRA
> has >800 more failures on GCC testsuite on power8. After the patch
> the
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'cpplib' has been submitted
by the Swedish team of translators. The file is available at:
http://translationproject.org/latest/cpplib/sv.po
(This file, 'cpplib-6.1-b20160131
Second Ping. Most recent patch posted here:
https://gcc.gnu.org/ml/gcc-patches/2015-12/msg01682.html
Regards,
Michael Collison
--
Michael Collison
Linaro Toolchain Working Group
michael.colli...@linaro.org
Hi,
The following was applied to the website to record additional GCC 6
changes for PowerPC. The changes passed XHTML verification.
Index: changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-6/changes.html,v
retrieving revision 1
Hi all,
this patch fixes bootstrap on FreeBSD PowerPC and hopefully all other
PowerPC targets which do not have float128 support.
The patch itself is a bandaid to survive stage4. We have to come up with
a better solution for FreeBSD and all other soft float targets which do
not support float
On 02/04/2016 07:30 AM, Richard Henderson wrote:
On 02/04/2016 12:46 AM, Richard Biener wrote:
As for a patch I'd repeatedly pondered on not stripping int <-> pointer
conversions at all, similar to what STRIP_SIGN_NOPS does. Don't remember
actually trying this or the fallout though.
I'll run
Am 03.02.2016 um 19:18 schrieb Janus Weil:
Hi,
2016-02-03 10:21 GMT+01:00 Manfred Schwarb :
here is a diagnostics patch, which makes sure that the responsible
flag is printed in several warning messages (for which this was still
missing).
if (source_size < result_size)
-gfc_warning (
I've committed a patch to the libgo library to update it to Go 1.6rc1,
the first release candidate for the Go 1.6 release. As usual with
major libgo updates, the change is too large to include here. I've
attached the changes to gccgo-specific files.
This update does not have many OS-specific cha
On 03/02/16 19:47 +0100, Jakub Jelinek wrote:
On Wed, Feb 03, 2016 at 10:42:37AM -0800, Mike Stump wrote:
On Feb 3, 2016, at 9:13 AM, David Malcolm wrote:
>> +pointer constants, so other constants such as false and
>> +(1 - 1) cannot be used where a null pointer is desired.
So, I’d leave this
this patch fixes bootstrap on FreeBSD PowerPC and hopefully all other
PowerPC targets which do not have float128 support.
The patch itself is a bandaid to survive stage4. We have to come up
with a better solution for FreeBSD and all other soft float targets
which do not support float128.
The patc
On Wed, 3 Feb 2016, Manfred Schwarb wrote:
> There are 2 things with translation, and there is a third issue:
> - As you noticed, breaking things differently means translation has to be
> done again.
> - Normally, each string is translated independently, and depending on the
> language there m
Hi!
rs6000_expand_atomic_compare_and_swap uses oldval directly in
a comparison instruction, but oldval might be a CONST_INT not suitable
for the instruction (such as in the testcase below in SImode comparison
0x8000 constant). We need to force those into register if they don't
satisfy the predica
Here is a new patch for PR target/68273. It makes the GCC calling conventions
compatible with LLVM so that the two agree with each other in all the cases
I could think of testing and it fixes the reported defect.
I couldn't get the GCC compatibility test to work (see
https://gcc.gnu.org/ml/gcc/2
On Wed, Feb 3, 2016 at 5:28 PM, Jakub Jelinek wrote:
> Hi!
>
> rs6000_expand_atomic_compare_and_swap uses oldval directly in
> a comparison instruction, but oldval might be a CONST_INT not suitable
> for the instruction (such as in the testcase below in SImode comparison
> 0x8000 constant). We ne
Richard Sandiford writes:
> Uros Bizjak writes:
>> On Tue, Feb 2, 2016 at 5:54 PM, Kyrill Tkachov
>> wrote:
>>> Hi Richard,
>>>
>>>
>>> On 02/02/16 14:56, Richard Sandiford wrote:
In PR 69577 we have:
A: (set (reg:V2TI X) ...)
B: (set (subreg:TI (reg:V2TI X) 0) ...
I added dg-timeout-factor support to compat.exp, so that one can use it in
struct-layout-1.exp test cases.
To use it, one can do something like:
diff --git a/gcc/testsuite/gcc.dg/compat/struct-layout-1_generate.c
b/gcc/testsuite/gcc.dg/compat/struct-layout-1_generate.c
index 80c7355..bc34f2a 1
Andrew Bennett writes:
>> -Original Message-
>> From: Matthew Fortune
>> Sent: 30 January 2016 16:46
>> To: Richard Sandiford; Steve Ellcey
>> Cc: gcc-patches@gcc.gnu.org; c...@codesourcery.com; Andrew Bennett
>> Subject: RE: [Patch, MIPS] Patch for PR 68400, a mips16 bug
>>
>> Richard Sa
In PR 69461, Vlad mentioned that in rs6000_legitimate_address_p, I was trying
to validate an address for TOC fusion, but I was using a predicate that looked
for a MEM instead of an address.
I bootstrapped the compiler on a little endian power8 and there were no
regressions. In addition, Segher Bo
On Wed, Feb 3, 2016 at 6:34 PM, Michael Meissner
wrote:
> In PR 69461, Vlad mentioned that in rs6000_legitimate_address_p, I was trying
> to validate an address for TOC fusion, but I was using a predicate that looked
> for a MEM instead of an address.
>
> I bootstrapped the compiler on a little en
On 02/03/2016 05:35 PM, Wilco Dijkstra wrote:
- tmp2 = targetm.gen_ccmp_first (&prep_seq_2, &gen_seq_2, rcode1,
-gimple_assign_rhs1 (gs1),
-gimple_assign_rhs2 (gs1));
-
It looks like after this patch tmp2 co
On 02/01/2016 08:13 AM, Mike Frysinger wrote:
We don't document the -mno-xxx variants for other flags here, and the
paragraph here specifically says "Each has a corresponding -mno- option
to disable use of these instructions". Drop the -mno-fma4 line.
2016-01-31 Mike Frysinger
* doc
On Feb 3, 2016, at 2:30 PM, Steve Ellcey wrote:
> Here is a new patch for PR target/68273.
So this doesn’t fix aarch64, c6x, epiphany, ia64, iq2000, rs6000, rx, sparc,
tilegx, tilepro or xtensa.
:-( That’s one of the problems by having each port copy and paste swaths of
code from other ports
On Feb 3, 2016, at 2:03 PM, Jonathan Wakely wrote:
> Yes, there are *dozens* of packages that fail to build due to "return
> false;" in a function that returns a pointer of some kind.
Wow, curious. Anyway, that removes my objection.
Index: ChangeLog
===
--- ChangeLog (revision 233123)
+++ ChangeLog (working copy)
@@ -1,3 +1,9 @@
+2016-02-03 H.J. Lu
+
+ * gcc.target/i386/iamcu/test_passing_unions.c (check_union_passing6):
+ Define only if CHECK_F
On 02/03/2016 04:56 AM, Richard Sandiford wrote:
gcc/
PR rtl-optimization/69577
* reginfo.c (record_subregs_of_mode): Add a partial_def parameter.
(find_subregs_of_mode): Update accordingly. Iterate over partial
definitions.
gcc/testsuite/
PR rtl-optimiz
I merged GCC trunk revision 233110 to the gccgo branch.
Ian
On Wed, Feb 3, 2016 at 1:40 PM, Patrick Palka wrote:
> On Tue, 2 Feb 2016, Jason Merrill wrote:
>
>> On 11/09/2015 04:30 AM, Patrick Palka wrote:
>>>
>>> + if (complain & tf_warning)
>>> + {
>>> + if (VAR_P (old_expr))
>>> + warning (0, "
On 02/03/2016 03:49 PM, Michael Meissner wrote:
On Wed, Feb 03, 2016 at 01:02:57PM -0500, Vladimir Makarov wrote:
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69461
The patch actually solves several issues. Before the patch LRA
has >800 more failures on GCC tes
From: Trevor Saunders
hi,
Joel said in http://gcc.gnu.org/ml/gcc/2016-01/msg00016.html we should drop
support for these targets because rtems has stopped supporting them, so this
marks them as obsolete and we can remove them in gcc 7.
tested building for {avr,h8300,m32r}-rtems without --enable-
I've committed the patch with the changes below. Just to clarify
my concern (since put to rest):
It was impossible to have null TYPE_MAX_VALUE until you introduced that
in compute_array_index_type, and thus we didn't test for it; if we
aren't doing that anymore I can't imagine where it would co
While attempting to write some code that uses the new x86 named address space
support in gcc 6, I found that __typeof is very unhelpful. In particular, given
int __seg_fs *ptr;
__typeof(*ptr) obj;
OBJ will not be type "int", but "int __seg_fs". Which means that you can't use
On 02/03/2016 09:36 PM, tbsaunde+...@tbsaunde.org wrote:
From: Trevor Saunders
hi,
Joel said in http://gcc.gnu.org/ml/gcc/2016-01/msg00016.html we should drop
support for these targets because rtems has stopped supporting them, so this
marks them as obsolete and we can remove them in gcc 7.
t
Hi Uros,
> -Original Message-
> From: Uros Bizjak [mailto:ubiz...@gmail.com]
> Sent: Wednesday, February 03, 2016 2:20 AM
> To: Stepanyan, Victoria
> Cc: gcc-patches@gcc.gnu.org; ger...@pfeifer.com; rguent...@suse.de;
> Kumar, Venkataramanan
> Subject: Re: Turnoff prefetching for -march=zn
99 matches
Mail list logo
