On Wed, Jan 15, 2014 at 2:19 PM, Peter Bergner wrote:
> Oops, forgot to CC the x86 maintainers. Is the i386.c change ok for 4.8?
>
> Peter
>
>
> Forwarded Message
> From: Peter Bergner
> To: gcc-patches@gcc.gnu.org
> Cc: Richard Biener , Jakub Jelinek
> , Vladimir Makarov
>
Tom de Vries writes:
> * The set of registers which are clobbered during a call by things like the
> plt
>- these are not picked up by the use-caller-save optimization. We need the
>hook to inform the compiler about these registers
Right, but...
> * And finally, registers clobbered in t
Hello!
No functional change.
2014-01-15 Uros Bizjak
* config/i386/i386.c (ix86_hard_regno_mode_ok): Use
VALID_AVX256_REG_OR_OI_MODE.
Bootstrapped for x86_64-linux-gnu and committed to mainline SVN.
Uros.
Index: config/i386/i386.c
=
On Thu, Jan 16, 2014 at 03:41:57AM +, Joern Rennecke wrote:
> On 15 January 2014 21:55, Jakub Jelinek wrote:
> ...
> > The patch removes the likely_spilled_retval stuff Joern wrote a few years
> > ago because I believe this change should obsolete that. But, have tried to
> > reproduce the ICE
4.8 has a number of strict-volatile-bitfields issues that can be fixed by
following patches.
trunk@205899, 205898, 205897, 205896, 203003
Tested on x86_64 and arm without regression.
OK to 4.8?
2013-09-28 Sandra Loosemore
gcc/
* expr.h (extract_bit_field): Remove packedp par
On Wed, 15 Jan 2014, Jakub Jelinek wrote:
> On Wed, Jan 15, 2014 at 02:06:24PM +0100, Richard Biener wrote:
> >
> > This should fix PR59822, us creating in valid SSA form when
> > hoisting a[i_2] out of a loop where i_2 is defined inside the loop.
> >
> > Bootstrap / regtest running on x86_64-un
Perfect. Thanks very much for the commit.
Regards,
Laurent
On 01/15/14 20:25, Jeff Law wrote:
On 01/09/14 07:17, Laurent Alfonsi wrote:
On 01/09/14 06:02, Jeff Law wrote:
On 01/08/14 02:05, Laurent Alfonsi wrote:
All,
I was looking at PR49718. I have enclosed a simple fix for this bug
On Wed, 15 Jan 2014, Jan Hubicka wrote:
> Hi,
> this patch fixes ICE in ipa-devirt that is caused by get_binfo_at_offset
> reporting NULL for a valid query. This is because how virtual inheritance
> is represented.
>
> Here we have chain A<-B<-C where A is a virtual base. We look for A within
>
Ping!
Thank you,
Tatiana Udalova
--
Hello,
I have reproduced the problem with mklog mentioned by Jakub:
> In my experience mklog is pretty much useless, e.g. if you add a new
> function, it will list the previous function as being modified rather
> than the new one, etc.
My focus w
ChangeLog is messed up with other one.
On Thu, Jan 16, 2014 at 3:33 PM, Terry Guo wrote:
> Hi,
>
> Current 4.8 branch will assign alu_reg attribute to the type of arm preload
> insn, which is clearly wrong. The attached patch intends to back port trunk
> patch to reclassify the type attribute as
On Wed, 15 Jan 2014, Jakub Jelinek wrote:
> Hi!
>
> As discussed in the PR, when combine combines something across a setter
> of a likely spilled non-fixed hard register, we may get RA ICE, as the
> combined insn might need for reload a hard reg that is live at the point
> where combiner has comb
* gcc.c-torture/execute/pr59747.c (fn1): Return a value.
Index: gcc.c-torture/execute/pr59747.c
===
--- gcc.c-torture/execute/pr59747.c (revision 206658)
+++ gcc.c-torture/execute/pr59747.c (working copy)
@@ -1,13 +1,1
Mike Stump writes:
> On Jan 14, 2014, at 7:25 AM, Richard Sandiford
> wrote:
>> Mike Stump writes:
>>> diff --git a/gcc/expmed.c b/gcc/expmed.c
>>> index ce063eb..720d8c1 100644
>>> --- a/gcc/expmed.c
>>> +++ b/gcc/expmed.c
>>> @@ -4963,6 +4963,7 @@ make_tree (tree type, rtx x)
>>> return
On Wed, Jan 15, 2014 at 4:53 PM, Marek Polacek wrote:
> We ICE on the following (invalid) testcase, because the DECL_ARG_TYPE
> is error_mark_node and useless_type_conversion_p doesn't check that
> it operates on a type.
>
> Regtested/bootstrapped on x86_64-linux, ok for trunk/4.8/4.7?
Ok.
Thank
On Wed, Jan 15, 2014 at 6:37 PM, Eric Botcazou wrote:
>> I know, I'm saying it may be possible to implement an equivalent
>> optimization without SSA form.
>
> Sure, but what would be the point of this duplication exactly?
To avoid ...
>> I'm saying even ESRA should be able to scalarize it just
Ping.
On 17 December 2013 15:35, Michael V. Zolotukhin
wrote:
> Hi everybody,
>
> Here is a set of patches implementing one more piece of offloading support in
> GCC. These three patches allow to build a host binary with target image and
> all
> tables embedded. Along with patches for libgomp
Ping.
On 17 December 2013 15:39, Michael V. Zolotukhin
wrote:
> Hi everybody,
>
> Here is a patch 2/3: Add tables generation.
>
> This patch is just a slightly modified patch sent a couple of weeks ago. When
> compiling with '-fopenmp' compiler generates a special symbol, containing
> addresses
Ping.
On 20 December 2013 20:46, Michael V. Zolotukhin
wrote:
>> This patch seems to make rather too many assumptions about host and
>> target compilers. Certainly code like this can't go into
>> target-independent code like lto-wrapper.
> That's true. The point of this patch was to show what is
Hi,
This patch is the first patch in a series of patches fixing Big-Endian
lane numbering. The goal of this series of patches is to make proper
bridge between pure GCC big-endian view on lane numbering and internal
architected view.
Approach taken is to catch lane indexing when internal vector la
On Wed, Jan 15, 2014 at 10:39 PM, Jeff Law wrote:
>
> Our SSA copy-prop passes do a pretty pathetic job at cleaning up after
> themselves when const/copy propagation exposes new trivial copies and
> constant initializations.
>
> This can be seen in the code for pr57904 after copyprop2 for bb2
>
>
Hi,
This patch changes get_lane intrinsics to provide a correct big-endian
indexing. This fixes numerous BE load and store issues based on getting
correct lane.
Is this good for trunk?
gcc/
2013-01-14 Alex Velenko
* config/aarch64/aarch64-simd.md
(aarch64_be_checked_get_la
Hi,
This patch by James Greenhalgh fixes "by-lane" patterns broken by
previous patches.
Regression tested on aarch64-none-elf and aarch64_be-none-elf
with no unexpected issues.
OK?
Thanks,
Alex
---
gcc/
2014-01-16 James Greenhalgh
* config/aarch64/aarch64-simd.md
(aarch64
> +/* Return true if T is a pointer to a zero-sized struct/union. */
> +
> +bool
> +pointer_to_zero_sized_aggr_p (tree t)
> +{
> + t = strip_pointer_operator (t);
> + return ((RECORD_OR_UNION_TYPE_P (t) || TREE_CODE (t) == ARRAY_TYPE)
> + && TYPE_SIZE (t)
> + && integer_zerop (TYPE_S
Hi,
In previous BE patches the way lane indexing in lanes is calculated has
been changed. To accommodate the change, arm neon intrinsics had to be
updated.
Is it okay?
/gcc/
2014-01-16 James Greenhalgh
Alex Velenko
* config/aarch64/arm_neon.h (vaddv_s8): __LANE0 cleanu
> Yes, like in the attached patch? OK for the trunk?
Unfortunately this broke again bootstrap with RTL checking enabled on x86-64:
/home/eric/svn/gcc/libgcc/libgcc2.c: In function '__negdi2':
/home/eric/svn/gcc/libgcc/libgcc2.c:71:1: internal compiler error: RTL check:
expected code 'reg', have
On Thu, Jan 16, 2014 at 12:50:10PM +0100, Eric Botcazou wrote:
> > +/* Return true if T is a pointer to a zero-sized struct/union. */
> > +
> > +bool
> > +pointer_to_zero_sized_aggr_p (tree t)
> > +{
> > + t = strip_pointer_operator (t);
> > + return ((RECORD_OR_UNION_TYPE_P (t) || TREE_CODE (t)
Ping ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58602
As a reminder, that prevent running lcov on kernel side.
http://sourceforge.net/p/ltp/mailman/message/31141937/
Thanks
Laurent
On 10/03/13 17:01, Laurent Alfonsi wrote:
Hi All,
We have discovered a bug on gcno file generation re
[AArch64] VDUP testcases
Hi,
This patch implements test cases for following NEON intrinsics:
vdup_lane_f32
vdup_lane_s[8,16]
vdup_lane_s[32,64]
vdup_n_[p,s,u][8,16]
vdup_n_[s,u][32,64]
vdupb_lane_[s,u]8
vduph_lane_[s,u]16
vdupd_lane_[f,s,u]64
vdups_lane_[f,s,u]32
vdupq_lane_[f,s][32,64]
vdupq_
Hi,
This patch fixes testcase vneg_f.c which was using an inconsistent
vector model causing problems for Big-Endian compiler.
Now testcase runs on both LE and BE without regressions.
Is it okay?
Kind regards,
Alex Velenko
gcc/testsuite/
2013-01-16 Alex Velenko
*/gcc.target/aar
On Thu, 2014-01-16 at 09:11 +0100, Uros Bizjak wrote:
> On Wed, Jan 15, 2014 at 2:19 PM, Peter Bergner wrote:
> > Backport from mainline
> > 2013-09-06 Jan Hubicka
> >
> > * config/i386/i386.c (ix86_hard_regno_mode_ok): AVX modes are valid
> > only when AVX is en
On Thu, Jan 16, 2014 at 1:39 PM, Peter Bergner wrote:
>> > Backport from mainline
>> > 2013-09-06 Jan Hubicka
>> >
>> > * config/i386/i386.c (ix86_hard_regno_mode_ok): AVX modes are valid
>> > only when AVX is enabled.
>>
>> OK for x86, with slight update, as su
This fixes the two remaining dataflow iteration order issues
in lcm.c. On the testcase from PR46590 (long function with
many loops) we get an improvement from
PRE : 13.85 (42%) usr 0.08 (16%) sys 13.93 (41%)
wall1067 kB ( 1%) ggc
TOTAL : 33.35
I've landed patches for libbacktrace and cp-demangle support in LLVM.
However, they required some changes (e.g. some files LLVM trunk were
modified after the last merge). This means that the next merge to GCC
(IIUC it won't happen anytime soon before GCC 4.9 release) will not be
clean. Sorry for de
On Mon, Jan 13, 2014 at 5:37 AM, Richard Biener wrote:
> On Wed, 27 Nov 2013, Jakub Jelinek wrote:
>
>> On Wed, Nov 27, 2013 at 10:53:56AM +0100, Richard Biener wrote:
>> > Hmm. I'm still thinking that we should handle this during the regular
>> > transform step.
>>
>> I wonder if it can't be don
Hi,
I found ipa_remove_stmt_references incorrectly iterates over
references after reference removal. When reference is removed, the
last one takes it's place and is not checked at all. It means we do
not remove all required references in some cases.
Here is a patch to fix it. Bootstrapped and tes
On Wed, Jan 15, 2014 at 08:36:09PM +, Charles Baylis wrote:
> Hi James,
>
> This commit (SVN r206045) seems to have introduced a problem when
> compiling multiple source files if a -mcpu option is also present on
> the command line.
>
> This can be reproduced in a arm-unknown-linux-gnueabihf
On 14/01/14 15:51, pins...@gmail.com wrote:
On Jan 14, 2014, at 7:19 AM, Alex Velenko wrote:
Hi,
This patch turns off the vec_perm patterns for aarch64_be, this should resolve
the issue highlighted here
http://gcc.gnu.org/ml/gcc-patches/2014-01/msg00321.html
With this patch applied, the t
The mklog script claims to write to stdout, but it actually modifies
the input file in-place.
OK to commit this change, which also updates the copyright dates?
diff --git a/contrib/mklog b/contrib/mklog
index fb0514f..4893e0c 100755
--- a/contrib/mklog
+++ b/contrib/mklog
@@ -1,5 +1,5 @@
#!/usr/b
On Thu, 2014-01-16 at 13:49 +0100, Uros Bizjak wrote:
> On Thu, Jan 16, 2014 at 1:39 PM, Peter Bergner wrote:
> > We were already testing for OImode, so do you want me to
> > remove the redundant compare and make the code look like
> > the following instead?
>
> Yes, just use [1] from mainline.
>
On 16 January 2014 14:26, James Greenhalgh wrote:
>
> At a guess, your configuration is set with --with-mode=thumb,
> and probably has a default architecture of armv4. With the first
> invocation of cc1 the -mcpu overrides the default architecture and
Apologies, I should have included my configur
On 16 January 2014 08:26, Jakub Jelinek wrote:
> I wonder if instead of not creating the LOG_LINKS we could just somehow taint
> them, add a flag to struct insn_link that we need to be careful about
> combining across that link, then in combine_instructions or the flags together
> from all the us
On 01/15/2014 01:58 PM, Jakub Jelinek wrote:
> On Wed, Jan 15, 2014 at 01:43:18PM -0800, Richard Henderson wrote:
>> --- /dev/null
>> +++ b/gcc/testsuite/gcc.target/i386/pr54694.c
>> @@ -0,0 +1,11 @@
>> +/* { dg-do compile } */
>> +/* { dg-options "-O" } */
>> +
>> +register void *hfp __asm__("%ebp
This patch fixes the problem that was noticed when we attempted to boostrap the
compiler on a little endian power8 system with the -O3 -mcpu=power8 options.
During the development of the power8 direct move patches, I put a guard test in
the 128-bit direct move insns to make the patterns big endian
This is a small patch that makes the -mcpu, -march and -mtune
command-line options case-insensitive, allowing e.g. -mcpu=Cortex-A15
-march=ARMv7.
Regression tested on arm-none-eabi with no issues; options passed onto
e.g. ld are always lowercase (as previously).
OK for trunk?
--Alan
ChangeLog:
On 16/01/14 07:33, Terry Guo wrote:
> Hi,
>
> Current 4.8 branch will assign alu_reg attribute to the type of arm preload
> insn, which is clearly wrong. The attached patch intends to back port trunk
> patch to reclassify the type attribute as load1. With this back port, the
> 4.8 bug PR59826 can
On 01/16/14 07:24, Ilya Enkovich wrote:
Hi,
I found ipa_remove_stmt_references incorrectly iterates over
references after reference removal. When reference is removed, the
last one takes it's place and is not checked at all. It means we do
not remove all required references in some cases.
Here
On 01/16/14 04:52, Eric Botcazou wrote:
Yes, like in the attached patch? OK for the trunk?
Unfortunately this broke again bootstrap with RTL checking enabled on x86-64:
/home/eric/svn/gcc/libgcc/libgcc2.c: In function '__negdi2':
/home/eric/svn/gcc/libgcc/libgcc2.c:71:1: internal compiler err
On Thu, Jan 16, 2014 at 11:08 AM, Michael Meissner
wrote:
> This patch fixes the problem that was noticed when we attempted to boostrap
> the
> compiler on a little endian power8 system with the -O3 -mcpu=power8 options.
>
> During the development of the power8 direct move patches, I put a guard
On 16/01/14 12:23, Alex Velenko wrote:
> Hi,
> This patch fixes testcase vneg_f.c which was using an inconsistent
> vector model causing problems for Big-Endian compiler.
>
> Now testcase runs on both LE and BE without regressions.
>
> Is it okay?
>
> Kind regards,
> Alex Velenko
>
> gcc/tests
On 16/01/14 16:15, Alan Lawrence wrote:
> This is a small patch that makes the -mcpu, -march and -mtune
> command-line options case-insensitive, allowing e.g. -mcpu=Cortex-A15
> -march=ARMv7.
>
> Regression tested on arm-none-eabi with no issues; options passed onto
> e.g. ld are always lowercase
Hello Everyone,
I would like to patch these two patches:
http://gcc.gnu.org/ml/gcc-patches/2014-01/msg00408.html -- _Cilk_for
http://gcc.gnu.org/ml/gcc-patches/2014-01/msg00116.html -- SIMD enabled
functions for C++
They have been under review for a while now (~1 month)
On 01/08/2014 02:46 PM, Iyer, Balaji V wrote:
+ /* Grain value, only used by _Cilk_for. */
+ tree grain;
Why can't the grain stay as a clause for the gimple form of the loop?
+ if (flag_enable_cilkplus && TREE_CODE (for_stmt) == CILK_FOR)
+{
+ tree it = TREE_VEC_ELT (OMP_FOR_INIT
Ping.
-Rong
On Mon, Jan 13, 2014 at 12:43 PM, Rong Xu wrote:
> Hi,
>
> This patch implements gcov-tool, a offline profile processing tool.
> This version supports merging two profiles with weights, and scaling
> the profile with a floating-point / fraction weight.
>
> Earlier discussion can be f
Hi,
While clarifying the documentation of the -mcpu, -march and -mtune
options for AArch64 and ARM I spotted that their behaviour is not
consistent.
This patch fixes that in the AArch64 port.
Now, -mcpu=$CPU is treated as a shorthand for -march=arch_of_$CPU and
-mtune=$CPU. -march and -mtune t
On Thu, Jan 16, 2014 at 08:06:07AM -0800, Richard Henderson wrote:
> On 01/15/2014 01:58 PM, Jakub Jelinek wrote:
> > On Wed, Jan 15, 2014 at 01:43:18PM -0800, Richard Henderson wrote:
> >> --- /dev/null
> >> +++ b/gcc/testsuite/gcc.target/i386/pr54694.c
> >> @@ -0,0 +1,11 @@
> >> +/* { dg-do compi
On Thu, Jan 16, 2014 at 12:29:44PM -0500, Jason Merrill wrote:
> >+ if (code == CILK_FOR)
> >+{
> >+ top_level_body = push_stmt_list ();
> >+ top_body = begin_omp_parallel ();
> >+}
>
> I wouldn't expect the front end to care that Cilk for is implemented
> using a parallel call;
On Thu, Jan 16, 2014 at 9:35 AM, Jakub Jelinek wrote:
> On Thu, Jan 16, 2014 at 08:06:07AM -0800, Richard Henderson wrote:
>> On 01/15/2014 01:58 PM, Jakub Jelinek wrote:
>> > On Wed, Jan 15, 2014 at 01:43:18PM -0800, Richard Henderson wrote:
>> >> --- /dev/null
>> >> +++ b/gcc/testsuite/gcc.targe
On Thu, Jan 16, 2014 at 09:40:33AM -0800, H.J. Lu wrote:
> On Thu, Jan 16, 2014 at 9:35 AM, Jakub Jelinek wrote:
> > On Thu, Jan 16, 2014 at 08:06:07AM -0800, Richard Henderson wrote:
> >> On 01/15/2014 01:58 PM, Jakub Jelinek wrote:
> >> > On Wed, Jan 15, 2014 at 01:43:18PM -0800, Richard Henders
Looking at this PR I noticed that there were other potential issues with
the implementation of this function, so I've essentially rewritten it.
We now far more consistently use gen_(high/low)part, and avoid
dereferencing REGNO when we don't have a register src.
R.
2014-01-16 Richard Earnshaw
On 01/16/2014 09:35 AM, Jakub Jelinek wrote:
> Wonder if the test should be turned into dg-do compile,
> or perhaps a hack like:
> int xmain() __asm__ ("main");
> int xmain()
> instead of
> int main()
> to avoid the dynamic stack realigning in main (limit the test to *linux*
> then?), supply main w
Hi all,
The Cortex-A53 and Cortex-A57 cores support the CRC32 and Crypto extensions to
the ARMv8-A architecture. This patch adds that information to their definitions
in aarch64-cores.def.
Tested aarch64-none-elf with no regressions.
Ok for trunk? (or next stage1)?
Thanks,
Kyrill
2014-01-1
On Thu, Jan 16, 2014 at 05:14:24PM +, Richard Earnshaw wrote:
> On 16/01/14 16:15, Alan Lawrence wrote:
> > This is a small patch that makes the -mcpu, -march and -mtune
> > command-line options case-insensitive, allowing e.g. -mcpu=Cortex-A15
> > -march=ARMv7.
> >
> > Regression tested on arm
On Thu, Jan 16, 2014 at 09:51:24AM -0800, Richard Henderson wrote:
> On 01/16/2014 09:35 AM, Jakub Jelinek wrote:
> > Wonder if the test should be turned into dg-do compile,
> > or perhaps a hack like:
> > int xmain() __asm__ ("main");
> > int xmain()
> > instead of
> > int main()
> > to avoid the
Tejas Belagod wrote:
Tejas Belagod wrote:
Hi,
Currently, CANNOT_CHANGE_MODE_CLASS is too restrictive wrt the mode-changes it
allows on FPREGs - it allows none at the moment. In fact, there are many mode
changes that are safe and can be allowed. For example, in a pattern like:
(subreg:S
The test gcc.c-torture/execute/pr59747.c fails on darwin13 at execution time
(Abort)
for all tested optimizations, -m32/-m64, and gcc versions before or after the
commit.
Should I
(1) reopen pr59749,
(2) open a new pr,
(3) let you handle the problem without further fuss?
For (1) or (2) do you n
On Thu, Jan 16, 2014 at 09:40:24AM +0100, Richard Biener wrote:
> That should be enough I think (we can't hoist PHIs anyway).
Ok, here is what I've finally successfully bootstrapped/regtested
on x86_64-linux and i686-linux, ok for trunk?
2014-01-16 Jakub Jelinek
* tree-vectorizer.h (s
On 11/25/13 23:50, David Holsgrove wrote:
Hi Michael,
I've attached the same patch based on latest gcc master.
Can this be applied to gcc-4_8-branch also.
thanks,
David
On 15 July 2013 14:53, David Holsgrove wrote:
Add SImode to cstoresf4's comparison operator, prevents ICE during combine
r
On 01/16/2014 10:21 AM, Jakub Jelinek wrote:
> So like this? Tested on x86_64 with
> make -k check-gcc RUNTESTFLAGS='--target_board=unix\{-m32,-m64\}
> i386.exp=pr9771-1.c'
>
> 2014-01-16 Jakub Jelinek
>
> PR debug/54694
> * gcc.target/i386/pr9771-1.c (main): Rename to...
>
On 01/16/14 04:49, Richard Biener wrote:
Well - the issue here is that inlining / IPA-CP propagates constant
arguments to direct uses which of course exposes constant propagation
opportunities. Now, copyprop doesn't to "real" constant propagation,
it just also propagates constants as if they we
On 20 December 2013 13:26, Richard Earnshaw wrote:
> On 19/12/13 17:40, Charles Baylis wrote:
>> Is it ok for 4.8, and should it be considered for 4.7?
>>
>
> Yes, provided it passes testing on those releases.
Results of testing 4.8:
All 3 patches:
0001-PR-target-59142-vfp_hard_register_opera
On 11/25/13 23:51, David Holsgrove wrote:
Hi Michael,
I've attached patch based on latest gcc master. Please let me know if
you need anything further.
thanks,
David
On 15 July 2013 14:44, David Holsgrove wrote:
Hi Michael,
On 18 March 2013 22:49, David Holsgrove wrote:
MicroBlaze doesn't
Hi,
g++.dg/debug/ra1.C fails on arm-none-eabi with the following message
because enum types in arm eabi are represented by the smallest integral
type:
warning: width of 'tree_base::code' exceeds its type [enabled by default]
This patch updates the test by changing the width of the 'code' bit
> On Wed, 15 Jan 2014, Jan Hubicka wrote:
>
> > Hi,
> > this patch fixes ICE in ipa-devirt that is caused by get_binfo_at_offset
> > reporting NULL for a valid query. This is because how virtual inheritance
> > is represented.
> >
> > Here we have chain A<-B<-C where A is a virtual base. We loo
On Wed, Jan 15, 2014 at 09:23:06PM +, Joseph S. Myers wrote:
> On Wed, 15 Jan 2014, Marek Polacek wrote:
>
> > +/* Return true if T is a pointer to a zero-sized struct/union. */
> > +
> > +bool
> > +pointer_to_zero_sized_aggr_p (tree t)
> > +{
> > + t = strip_pointer_operator (t);
> > + ret
On 01/16/14 11:23, Dominique Dhumieres wrote:
The test gcc.c-torture/execute/pr59747.c fails on darwin13 at execution time
(Abort)
for all tested optimizations, -m32/-m64, and gcc versions before or after the
commit.
Should I
(1) reopen pr59749,
(2) open a new pr,
(3) let you handle the proble
On 01/16/14 04:52, Eric Botcazou wrote:
Yes, like in the attached patch? OK for the trunk?
Unfortunately this broke again bootstrap with RTL checking enabled on x86-64:
/home/eric/svn/gcc/libgcc/libgcc2.c: In function '__negdi2':
/home/eric/svn/gcc/libgcc/libgcc2.c:71:1: internal compiler err
Hi!
As the following testcase shows, if target of a gather intrinsic
is e.g. a MEM, we shouldn't use it as target, because it fails
the output operand predicate.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
ok for trunk/4.8?
2014-01-16 Jakub Jelinek
PR target/
The following patch fixes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59835
Committed as rev. 206676.
2014-01-16 Vladimir Makarov
PR rtl-optimization/59835
* ira.c (ira_init_register_move_cost): Increase cost for
impossible modes.
Index: ira.c
==
Hi!
Before r200211 expand_expr_real_1 (and other places) used
const_value_known_p which just returned a bool whether the DECL_INITIAL
is usable, but now it has 3 possible return values, error_mark_node
for unusable initial, NULL_TREE for no DECL_INITIAL, but const var
(so, assuming zero initializa
On Thu, Jan 16, 2014 at 8:05 PM, Jakub Jelinek wrote:
> As the following testcase shows, if target of a gather intrinsic
> is e.g. a MEM, we shouldn't use it as target, because it fails
> the output operand predicate.
>
> Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
> ok f
The following patch fixes an arm wrong generation by LRA
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59609
The patch was bootstrapped and tested on x86/x86-64.
Committed as rev. 206677.
2014-01-16 Vladimir Makarov
PR middle-end/59609
* lra-constraints.c (process_alt_op
My preference would be to turn -Wreturn-type on by default, but not
create the separate -Wmissing-return flag. As I argued in 2002, there
should only be one flag.
To avoid spurious warnings on code with infinite loops we could add a
simple check for infinite loops and suppress the warning in
Jakub Jelinek wrote:
>Hi!
>
>Before r200211 expand_expr_real_1 (and other places) used
>const_value_known_p which just returned a bool whether the DECL_INITIAL
>is usable, but now it has 3 possible return values, error_mark_node
>for unusable initial, NULL_TREE for no DECL_INITIAL, but const var
>
Jakub Jelinek wrote:
>On Thu, Jan 16, 2014 at 09:40:24AM +0100, Richard Biener wrote:
>> That should be enough I think (we can't hoist PHIs anyway).
>
>Ok, here is what I've finally successfully bootstrapped/regtested
>on x86_64-linux and i686-linux, ok for trunk?
Ok.
Thanks,
Richard.
>2014-01-
The testcase noted that builtin_LINE used in a default argument was
getting the location of the call in one case, and the location of the
function declaration in another. The way it is used in default
arguments suggests that the intent is for it to have the location of the
call. This patch up
On Thu, Jan 16, 2014 at 02:54:14PM -0500, Jason Merrill wrote:
> commit 4088607eba17cb79c9bda0d5e2829705c75386b8
> Author: Jason Merrill
> Date: Thu Jan 16 13:54:35 2014 -0500
>
> PR c++/59821
> * tree.c (bot_manip): Update the location of builtin_LINE and
> builtin_FILE calls
On Wed, 2014-01-15 at 22:47 -0700, Jeff Law wrote:
> On 01/15/14 21:23, Andrew Pinski wrote:
> >> Tested on mips-mti-linux-gnu with no regressions.
> >>
> >> OK to checkin?
> >
> > No, this really should be fixed in the target side. In fact for MIPS
> > there is an instruction which does a condit
On 01/16/2014 03:17 PM, Jakub Jelinek wrote:
On Thu, Jan 16, 2014 at 02:54:14PM -0500, Jason Merrill wrote:
commit 4088607eba17cb79c9bda0d5e2829705c75386b8
Author: Jason Merrill
Date: Thu Jan 16 13:54:35 2014 -0500
PR c++/59821
* tree.c (bot_manip): Update the location of bui
On 01/07/14 09:16, Bernd Schmidt wrote:
This is PR56791. The address inside of an autoinc is reloaded, and the
autoinc is reloaded, but the reload insns are emitted in the wrong order.
As far as I can tell, this is because find_reloads_address_1 has two
methods of pushing a reload for an autoinc
On Thu, Jan 16, 2014 at 12:37 PM, Steve Ellcey wrote:
> On Wed, 2014-01-15 at 22:47 -0700, Jeff Law wrote:
>> On 01/15/14 21:23, Andrew Pinski wrote:
>
>> >> Tested on mips-mti-linux-gnu with no regressions.
>> >>
>> >> OK to checkin?
>> >
>> > No, this really should be fixed in the target side.
Here are a few things.
+ if (g_expr.value && TREE_CODE (g_expr.value) == C_MAYBE_CONST_EXPR)
+ {
+ error_at (input_location, "cannot convert grain to long integer.\n");
+ c_parser_skip_to_pragma_eol (parser);
+ }
Remove final period. Also, where's the testcase
On Wed, 2014-01-15 at 22:47 -0700, Jeff Law wrote:
> > No, this really should be fixed in the target side. In fact for MIPS
> > there is an instruction which does a conditional move based on the FP
> > CC register (movt/movf). So you need to look into why the wrong
> > pattern is being selected
On 01/16/14 04:52, Eric Botcazou wrote:
Yes, like in the attached patch? OK for the trunk?
Unfortunately this broke again bootstrap with RTL checking enabled on x86-64:
/home/eric/svn/gcc/libgcc/libgcc2.c: In function '__negdi2':
/home/eric/svn/gcc/libgcc/libgcc2.c:71:1: internal compiler err
On Thu, Jan 16, 2014 at 02:31:09PM -0700, Jeff Law wrote:
> +2014-01-16 Jeff Law
> +
> + * ree.c (combine_set_extension): Correct test for changing number
> + of hard registers when widening a reaching definition.
> +
> 2014-01-16 Bernd Schmidt
>
> PR middle-end/56791
> diff
On Wed, Jan 15, 2014 at 8:39 PM, Jan Hubicka wrote:
>>
>> In that case should we call gcov_error when IN_LIBGCOV? One
>> possibility would be to simply make gcov_nonruntime_assert be defined
>> as if (!EXPR) gcov_error in the IN_LIBGCOV case. But I think what you
>> wanted here was to reduce libgc
> On Wed, Jan 15, 2014 at 8:39 PM, Jan Hubicka wrote:
> >>
> >> In that case should we call gcov_error when IN_LIBGCOV? One
> >> possibility would be to simply make gcov_nonruntime_assert be defined
> >> as if (!EXPR) gcov_error in the IN_LIBGCOV case. But I think what you
> >> wanted here was to
On Thu, 2014-01-16 at 13:16 -0800, Andrew Pinski wrote:
> I think the following patch to mips.c should fix the issue:
> @@ -8092,7 +8125,7 @@ mips_print_operand (FILE *file, rtx op, int letter)
> case 't':
>{
> int truth = (code == NE) == (letter == 'T');
> - fputc ("zfn
several test cases started failing as a result of making the size of the
wide-int buffer smaller.
this patch fixes them. This failure was unrelated to the wide-int
buffer size directly, but a hard constant in the truck code was replaced
by MAX_BITSIZE_MODE_ANY_INT when it should have been repl
On Thu, Jan 9, 2014 at 5:13 AM, Paolo Carlini wrote:
> On 01/08/2014 11:47 PM, Tim Shen wrote:
>>
>> On Wed, Jan 8, 2014 at 5:38 PM, Paolo Carlini
>> wrote:
>>>
>>> I agree, it's probably fine for now, but please actually attach the patch
>>> ;)
>>
>> Oops sorry >.<
>
> Jon, is this version Ok wi
On Thu, Jan 16, 2014 at 3:22 PM, Steve Ellcey wrote:
> On Thu, 2014-01-16 at 13:16 -0800, Andrew Pinski wrote:
>
>> I think the following patch to mips.c should fix the issue:
>> @@ -8092,7 +8125,7 @@ mips_print_operand (FILE *file, rtx op, int letter)
>> case 't':
>>{
>> int
1 - 100 of 105 matches
Mail list logo
