On Friday, January 08, 2016 10:05:25 AM Richard Biener wrote:
> On Tue, 5 Jan 2016, Thomas Preud'homme wrote:
> > Hi,
> >
> > bswap optimization pass generate wrong code on big endian targets when the
> > result of a bit operation it analyzed is a partial load of
On Thursday, January 21, 2016 09:21:52 AM Richard Biener wrote:
> On Thu, 21 Jan 2016, Thomas Preud'homme wrote:
> > On Friday, January 08, 2016 10:05:25 AM Richard Biener wrote:
> > > On Tue, 5 Jan 2016, Thomas Preud'homme wrote:
> > > > Hi,
> > >
Ping?
On Monday, January 18, 2016 11:33:47 AM Thomas Preud'homme wrote:
> On Wednesday, January 13, 2016 06:39:20 PM Bernd Schmidt wrote:
> > On 01/12/2016 08:55 AM, Thomas Preud'homme wrote:
> > > On Monday, January 11, 2016 04:57:18 PM Bernd Schmidt wrote:
> >
Hi Bernd,
First of all, my apologize for the late reply. I was in holidays the past week
to celebrate Chinese new year.
On Friday, February 12, 2016 05:28:43 PM Bernd Schmidt wrote:
> PR69714 is an issue where the bswap pass makes an incorrect
> transformation on big-endian targets. The source h
value, converted to the result type, is the resulting value; otherwise, the
behavior is undefined."
ChangeLog entry is as follows:
2015-07-28 Thomas Preud'homme
PR tree-optimization/66828
* tree-ssa-math-opts.c (perform_symbolic_merge): Change type of inc
from i
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Thomas Preud'homme
>
> ChangeLog entry is as follows:
>
> 2015-07-28 Thomas Preud'homme
>
> PR tree-optimization/66828
> * tree-ssa-math-opts.c
ensure these
will be recomputed.
ChangeLog entries are as follows:
2015-07-31 Thomas Preud'homme
PR tree-optimization/67043
* loop-invariant.c (find_defs): Force recomputation of all luids.
2015-07-29 Thomas Preud'homme
PR tree-optimization/67043
Hi,
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Thomas Preud'homme
> Sent: Tuesday, July 28, 2015 3:04 PM
>
> > From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> > ow...@gcc.gnu.org] On Behalf Of Thomas Preud&
missing type specifier and checking for .word and similar directive instead
of the number of movt.
The new test passes for all of -mcpu=cortex-m{3,4,7} but fail when removing the
-mslow-flash-data switch.
ChangeLog entry is as follows:
*** gcc/testsuite/ChangeLog ***
2015-11-04 Thomas
We decided to apply this to ARM/embedded-5-branch.
Best regards,
Thomas
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Andre Vieira
> Sent: Wednesday, October 28, 2015 1:03 AM
> To: gcc-patches@gcc.gnu.org
> Subject: Re:
an effective
target for attr-simd-3.c testcase.
ChangeLog entry is as follows:
*** gcc/testsuite/ChangeLog ***
2015-12-08 Thomas Preud'homme
PR testsuite/68629
* lib/target-supports.exp (check_effective_target_cilkplus): Also
check that compiling with -fcilkplus
gcc.target/arm/lto/pr65837 fails on M profile ARM targets because of lack of
neon instructions. This patch adds the necessary arm_neon_ok effective target
requirement to avoid running this test for such targets.
ChangeLog entry is as follows:
* gcc/testsuite/ChangeLog ***
2015-12-08 Thomas
I suppose people were busy when I posted this patch and it got forgotten
since so here is a little ping.
Best regards,
Thomas
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Thomas Preud'homme
> Sent
the
infrastructure necessary for the detection to also cleanup the stmts that
become useless when the bswap optimization is performed.
*** gcc/ChangeLog ***
2014-08-01 Thomas Preud'homme
* tree-ssa-math-opts.c (struct usedtree): New.
(find_bswap_or_nop_1): Change prototy
regression were observed on any of the tests. The ChangeLog is as follows:
2014-08-11 Thomas Preud'homme
* gimple-fold.c (fold_ctor_reference): Don't fold in presence of
bitfields, that is when size doesn't match the size of type or the
size of the cons
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Thomas Preud'homme
>
> No regression were observed on any of the tests. The ChangeLog is as
> follows:
>
>
> 2014-08-11 Thomas Preud'homme
>
> * gimple-
://sourceware.org/ml/binutils/2014-08/msg00014.html
The ChangeLog is as follows:
*** gcc/ChangeLog ***
2014-07-14 Thomas Preud'homme
* config/arm/arm.c (dump_minipool): Fix alignment in minipool of
values whose size is less than MINIPOOL_FIX_SIZE on big endian target.
*** gcc/test
(think #ifdef)
would not be analyzed.
Note that the tests were written independently of the code so as to have more
confidence in the patch.
ChangeLog are as follows:
*** gcc/ChangeLog ***
2014-08-08 Thomas Preud'homme
PR middle-end/60070
* doc/invoke.texi (fno-float): A
> From: Marc Glisse [mailto:marc.gli...@inria.fr]
> Sent: Tuesday, August 12, 2014 5:47 PM
>
>
> Are you sure you want something that strict? If there are floats in the
> code but the compiler manages to get rid of them, it won't cause any
> trouble with the ABI. Besides, if you #include a header
> From: Richard Earnshaw
> Sent: Monday, August 11, 2014 4:54 PM
>
> I think this is the wrong place for this sort of fix up. HFmode values
> are fixed up in the consttable_4 pattern and it looks wrong to be that
> HImode values are then fixed up in a different place. We should be
> consistent a
> From: Richard Biener [mailto:richard.guent...@gmail.com]
> Sent: Monday, August 11, 2014 8:29 PM
>
> That's now extra compares (the operand_equal_p check now does
> a check that can be derived transitively).
>
> So - ok with the operand_equal_p cehck removed.
>
> Also see if this can be backpo
> From: Marek Polacek [mailto:pola...@redhat.com]
> Sent: Tuesday, August 12, 2014 5:43 PM
> On Tue, Aug 12, 2014 at 11:34:35AM +0200, Jakub Jelinek wrote:
> >
> > This looks wrong. c_token_starts_typename is just a function which tells
> > you if certain token can start a typename, issuing diagno
Ping?
Best regards,
Thomas
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Thomas Preud'homme
> Sent: Thursday, August 07, 2014 1:57 PM
> To: gcc-patches@gcc.gnu.org
> Subject: RE: [PATCH] Fix c
Ping?
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Thomas Preud'homme
> Sent: Thursday, August 07, 2014 6:56 PM
> To: gcc-patches@gcc.gnu.org
> Subject: [PATCH] Cancel bswap opt when intermediate s
its default
value. Then it can decide whether to set a given high register as caller saved
or not when optimizing for size based on this information.
ChangeLog are as follows:
*** gcc/ChangeLog ***
2014-08-15 Thomas Preud'homme
* config/arm/arm.c (arm_conditional_register_usage):
Ping?
> > -Original Message-
> > From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> > ow...@gcc.gnu.org] On Behalf Of Thomas Preud'homme
> > Sent: Thursday, August 07, 2014 1:57 PM
> > To: gcc-patches@gcc.gnu.org
> > Subject: RE: [PATC
> From: Richard Earnshaw
> Sent: Monday, August 18, 2014 6:34 PM
> >
> > The problem is that in the pattern for constable_4 we don't have the
> information
> > about the access mode for this entry. In the testcase along this patch the
> rtx
> > manipulated in the pattern is VOIDmode while the acces
Ping?
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Thomas Preud'homme
> Sent: Wednesday, August 20, 2014 9:28 AM
> To: gcc-patches@gcc.gnu.org
> Subject: [PATCH][ARM] Fix -fcall-saved-rX for X &g
/ChangeLog:
2014-08-29 Thomas Preud'homme
* tree-ssa-math-opts.c (struct symbolic_number): Clarify comment about
the size of byte markers.
(do_shift_rotate): Fix confusion between host, target and marker byte
size.
(verify_symbolic_number_p): Lik
Ping?
> > -Original Message-
> > From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> > ow...@gcc.gnu.org] On Behalf Of Thomas Preud'homme
> > Sent: Wednesday, August 20, 2014 9:28 AM
> > To: gcc-patches@gcc.gnu.org
> > Subject: [
angeLog are as follows:
*** gcc/ChangeLog ***
2014-09-30 Thomas Preud'homme
PR tree-optimization/63259
* tree-ssa-math-opts.c (pass_optimize_bswap::execute): Also consider
bswap in LROTATE_EXPR and RROTATE_EXPR statements.
*** gcc/testsuite/ChangeLog **
> From: Jakub Jelinek [mailto:ja...@redhat.com]
> Sent: Wednesday, October 08, 2014 2:39 PM
>
> Doesn't it turn 16-bit {L,R}ROTATE_EXPR used alone into
> __builtin_bswap16?
> For those the question is if the canonical GIMPLE should be the rotation
> or
> byteswap, I'd think rotation would be perha
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Thomas Preud'homme
> Sent: Wednesday, October 08, 2014 2:43 PM
> > Also, perhaps you could short-circuit this if the rotation isn't by constant
Note that do_shift_rotate alre
Ping?
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Thomas Preud'homme
> Sent: Monday, September 29, 2014 3:33 PM
> To: gcc-patches@gcc.gnu.org
> Subject: [PATCH, C++] Fix PR63366: __complex not eq
Hi Richard,
I realized thanks to Christophe Lyon that a shift was not right: the shift count
is a number of bytes instead of a number of bits.
This extra patch fixes the problem.
ChangeLog are as follows:
*** gcc/ChangeLog ***
2014-09-26 Thomas Preud'homme
* tree-ssa-math-o
> From: Christophe Lyon [mailto:christophe.l...@linaro.org]
> Sent: Tuesday, October 21, 2014 10:03 PM
> > +typedef int SItype __attribute__ ((mode (SI)));
> What's the purpose of this? It seems unused.
Sigh. Bad copy/paste from optimize-bswapsi-1.c
I'll add it to my patch for pr63259.
> I beli
> From: Christophe Lyon [mailto:christophe.l...@linaro.org]
> Sent: Sunday, October 26, 2014 4:40 PM
> I tried to modify check_effective_target_bswap
> and added:
> + } else {
> + if { [istarget arm*-*-*]
> +&& [check_no_compiler_messages_nocache arm_v6_or_later
> ob
.
ChangeLog is as follows:
2014-05-29 Thomas Preud'homme
PR tree-optimization/61328
* tree-ssa-math-opts.c (init_symbolic_number): Extract symbolic number
initialization from find_bswap_or_nop_1.
(find_bswap_or_nop_1): Test return value of find_bswap_or_
way:
1) prevent size extension of a bitwise expression
2) record the type of the bitwise expression instead of its size (the size can
be determined from the type)
3) use this type to perform a double cast as explained above
2014-05-30 Thomas Preud'homme
PR tree-optimization/613
homas Preud'homme
PR tree-optimization/61320
* tree-ssa-math-opts.c (bswap_replace): Cancel bswap optimization when
load is unaligned and would be slow for this target.
*** gcc/testsuite/ChangeLog ***
2014-06-03 Thomas Preud'homme
* gcc.dg/optimize-bs
> From: Christophe Lyon [mailto:christophe.l...@linaro.org]
> On 29 May 2014 11:58, Thomas Preud'homme
> wrote:
> >
> > Does the patch solve the problem you had? What about you Christophe?
> >
> >
>
> Hi Thomas,
>
> After a quick test, it looks
Thomas Preud'homme
+
+ * MAINTAINERS (Write After Approval): Add myself.
+
2014-06-03 Andrew Bennett
* MAINTAINERS (Write After Approval): Add myself.
diff --git a/MAINTAINERS b/MAINTAINERS
index 12c123d..71206e7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -501,6 +
> From: Richard Biener [mailto:richard.guent...@gmail.com]
>
> I'd rather change the comparisons
>
> - if (n->size < (int)sizeof (int64_t))
> -n->n &= ((uint64_t)1 << (n->size * BITS_PER_UNIT)) - 1;
> + if (bitsize / BITS_PER_UNIT < (int)sizeof (int64_t))
> +n->n &= ((uint64_t)1 << bits
> From: Richard Biener [mailto:richard.guent...@gmail.com]
>
> Err, but if you zero-extend directly to the target type you have the
> correct result, too.
Yep but in some case we need sign extend (32 bit bitwise OR stored
into 64 bit result). As I said, the logic could be simplified by sign
exten
:
*** gcc/ChangeLog ***
2014-06-04 Thomas Preud'homme
* ChangeLog (2014-05-23): Fix ChangeLog entry to refer to target
endianness instead of host endianness.
* tree-ssa-math-opts.c (find_bswap_or_nop_1): Likewise in dumps and
comments.
*** gcc/testsuite/Chan
> From: Richard Biener [mailto:richard.guent...@gmail.com]
> On Wed, Jun 4, 2014 at 9:04 AM, Thomas Preud'homme
> wrote:
> >
> > Great. What about you Andreas? Does it work fine for you? If yes, is this ok
> for trunk?
>
> Ok.
>
> Thanks,
> Richard.
s per GCC write access policies.
ChangeLog:
2014-06-09 Thomas Preud'homme
* tree-ssa-math-opts.c (find_bswap_or_nop_load): Check return value of
init_symbolic_number ().
diff --git a/gcc/tree-ssa-math-opts.c b/gcc/tree-ssa-math-opts.c
index a928ad9..1f011a6 100644
--- a/gc
as well).
ChangeLog are changed as follows:
*** gcc/ChangeLog ***
2014-06-05 Thomas Preud'homme
PR tree-optimization/61375
* tree-ssa-math-opts.c (init_symbolic_number): Cancel optimization if
symbolic number cannot be represented in an unsigned HOST_WID
> From: Richard Biener [mailto:richard.guent...@gmail.com]
> Sent: Wednesday, June 04, 2014 5:39 PM
> To: Thomas Preud'homme
>
>
> I'm failing to get why you possibly need two casts ... you should
> only need one, from the bswap/load result to the final type
>
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Thomas Preud'homme
>
> Is this OK for trunk? Does this bug qualify for a backport patch to
> 4.8 and 4.9 branches?
I forgot to mention that this was tested via bootstrap on
x86_64-l
the
original load, thus avoiding this problem.
ChangeLog entries for this fix are:
*** gcc/ChangeLog ***
2014-06-16 Thomas Preud'homme
* tree-ssa-math-opts.c (find_bswap_or_nop_1): Adapt to return a stmt
whose rhs's first tree is the source expression inst
b/gcc/ChangeLog
index 1e35bbe..0559b7f 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,16 @@
+2014-06-12 Thomas Preud'homme
+
+ PR tree-optimization/61306
+ * tree-ssa-math-opts.c (struct symbolic_number): Store type of
+ expression instead of its size.
+
> From: Jakub Jelinek [mailto:ja...@redhat.com]
> Sent: Thursday, June 19, 2014 1:54 AM
>
> Seems there are actually two spots with this, not just one.
>
> Completely untested fix:
>
> 2014-06-18 Jakub Jelinek
>
> * tree-ssa-math-opts.c (do_shift_rotate, find_bswap_or_nop_1):
> Cast
>
> From: Richard Biener [mailto:richard.guent...@gmail.com]
> Sent: Tuesday, June 10, 2014 5:05 PM
>
> Backports are welcome - please post a patch.
>
Sorry for the delay. Here you are:
diff --git a/gcc/testsuite/gcc.c-torture/execute/pr61375.c
b/gcc/testsuite/gcc.c-torture/execute/pr61375.c
new
> From: Jakub Jelinek [mailto:ja...@redhat.com]
> Sent: Monday, June 23, 2014 4:37 PM
>
> On Mon, Jun 23, 2014 at 10:18:16AM +0200, Richard Biener wrote:
> > > --- a/gcc/tree-ssa-math-opts.c
> > > +++ b/gcc/tree-ssa-math-opts.c
> > > @@ -1741,6 +1741,8 @@ find_bswap_1 (gimple stmt, struct
> symbol
> From: Jakub Jelinek [mailto:ja...@redhat.com]
> Sent: Monday, June 23, 2014 4:59 PM
>
> Host could e.g. in theory have CHAR_BIT 32, while target BITS_PER_UNIT 8
> (otherwise bswap pass would give up). sizeof (unsigned HOST_WIDE_INT)
> could
> very well be 2 in that case.
In this case the pass
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Thomas Preud'homme
>
> However
> although the original comments on struct symbolic_number implies that
> there is a mapping between host bytes (the bytes of the symbolic number)
Ok, what about the following patch and associated ChangeLog entries?
2014-06-24 Thomas Preud'homme
PR tree-optimization/61375
* tree-ssa-math-opts.c (find_bswap_or_nop_1): Cancel optimization if
symbolic number cannot be represented in an unsigned HOST_WID
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Thomas Preud'homme
> Sent: Thursday, June 19, 2014 1:36 PM
>
> Richard, given this issue, I think we should wait a few more days before I
> commit
> A backported (and fixed of
> From: Richard Biener [mailto:richard.guent...@gmail.com]
> Sent: Friday, June 27, 2014 4:49 PM
>
> FIne with me now.
Commited.
Best regards,
Thomas
Ping?
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Thomas Preud'homme
> Sent: Thursday, June 26, 2014 9:11 AM
> To: 'Jakub Jelinek'
> Cc: Richard Biener; GCC Patches
> Subject: R
byte, the way it is used in the code (even before any of
my patch) shows that it uses a fixed size of 8 [2].
[2] Note that since the pass is only active for targets with BITS_PER_UNIT ==
8, it might be using the target byte size.
gcc/ChangeLog:
2014-07-04 Thomas Preud'homme
*
> From: Jeff Law [mailto:l...@redhat.com]
> Sent: Tuesday, May 12, 2015 4:17 AM
>
> On 05/06/2015 03:47 AM, Thomas Preud'homme wrote:
> > Ping?
> Something to consider as future work -- I'm pretty sure PRE sets up the
> same kind of problematical pattern with a n
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Thomas Preud'homme
>
> > From: Jeff Law [mailto:l...@redhat.com]
> > Sent: Tuesday, May 12, 2015 4:17 AM
> >
> > >>
> > >> +
> > >>
> From: Jeff Law [mailto:l...@redhat.com]
> Sent: Wednesday, May 13, 2015 4:05 AM
> OK for the trunk.
>
> Thanks for your patience,
Thanks. Committed with the added "PR rtl-optimization/64616" to both
ChangeLog entries.
Best regards,
Thomas
hat.
ChangeLog entries are as follow:
*** gcc/ChangeLog ***
2015-05-18 Thomas Preud'homme
PR rtl-optimization/66168
* loop-invariant.c (move_invariant_reg): Set inv->reg to destination
of inv->insn when moving an invariant without introducing a temporary
> From: Steven Bosscher [mailto:stevenb@gmail.com]
> Sent: Tuesday, May 19, 2015 7:21 PM
>
> Not OK.
> This will break in move_invariants() when it looks at REGNO (inv->reg).
Indeed. I'm even surprised all tests passed. Ok I will just prevent moving
in such a case. I'm running the tests now a
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Thomas Preud'homme
> > From: Steven Bosscher [mailto:stevenb@gmail.com]
> > Sent: Tuesday, May 19, 2015 7:21 PM
> >
> > Not OK.
> > This will break in move_inva
> From: Jeff Law [mailto:l...@redhat.com]
> Sent: Saturday, May 23, 2015 6:54 AM
> >
> > - if (!can_move_invariant_reg (loop, inv, reg))
> > + if (!can_move_invariant_reg (loop, inv, dest))
> Won't this run into into the same problem if DEST is a SUBREG?
One of the very first test in can
Ping?
> -Original Message-
> From: Thomas Preud'homme [mailto:thomas.preudho...@arm.com]
> Sent: Thursday, April 30, 2015 3:19 PM
> To: Thomas Preud'homme; Richard Earnshaw; 'gcc-patches@gcc.gnu.org';
> Marcus Shawcroft; Ramana Radhakrishnan
> (raman
> From: Jeff Law [mailto:l...@redhat.com]
> Sent: Wednesday, May 27, 2015 11:24 PM
> Ah, OK. I was looking at the code prior to the call for
> can_move_invariant_reg in move_invariant_reg which implies that DEST
> can
> be a subreg, but REG can not.
>
> But with that check in can_move_invariant_r
Ping?
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Thomas Preud'homme
> Sent: Tuesday, March 03, 2015 12:02 PM
> To: 'Bernhard Reutner-Fischer'; gcc-patches@gcc.gnu.org; 'Paolo Bo
Committed. I'll wait a week and then ask for approval for a backport to 5.1.1
once 5.1 is released.
Best regards,
Thomas
> -Original Message-
> From: Kenneth Zadeck [mailto:zad...@naturalbridge.com]
> Sent: Monday, April 20, 2015 9:26 PM
> To: Thomas Preud'ho
> From: Jeff Law [mailto:l...@redhat.com]
> Sent: Friday, April 24, 2015 10:59 AM
>
Hi Jeff,
> > +
> > +static bool
> > +cprop_reg_p (const_rtx x)
> > +{
> > + return REG_P (x) && !HARD_REGISTER_P (x);
> > +}
> How about instead this move to a more visible location (perhaps a macro
> in regs.h
> From: Jeff Law [mailto:l...@redhat.com]
> Sent: Friday, April 24, 2015 11:15 AM
>
> So revised review is "ok for the trunk" :-)
Committed.
Best regards,
Thomas
I just committed the obvious fix below that fix build failure introduced by
revision 222371.
*** gcc/ChangeLog ***
2015-04-24 Thomas Preud'homme
* config/arm/unknown-elf.h (ASM_OUTPUT_ALIGNED_DECL_LOCAL): fix
ternary operator in fprintf and harmonize spacing.
diff --
Hi,
first of all, sorry for the delay. We quickly entered stage 4 and I thought
it was best waiting for stage 1 to update you on this.
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Thomas Preud'homme
>
> Of course both approaches
> From: Jeff Law [mailto:l...@redhat.com]
> Sent: Saturday, April 25, 2015 3:00 AM
> Do you have a testcase where this change can result in better generated
> code. If so please add that testcase. It's OK if it's ARM specific.
Hi Jeff,
Last time I tried I couldn't reduce the code to a small tes
> From: Jeff Law [mailto:l...@redhat.com]
> Sent: Saturday, April 25, 2015 2:57 AM
> > +static rtx
> > +sign_extend_short_imm (rtx src, machine_mode mode, unsigned int
> prec)
> > +{
> > + if (GET_MODE_PRECISION (mode) < prec && CONST_INT_P (src)
> > + && INTVAL (src) > 0 && val_signbit_know
> From: Marcus Shawcroft [mailto:marcus.shawcr...@gmail.com]
> Sent: Thursday, February 05, 2015 5:17 PM
> >
> > *** gcc/ChangeLog ***
> >
> > 2015-01-26 Thomas Preud'homme thomas.preudho...@arm.com
> >
> > * config.gcc: Add cortex-a57-f
Here is an updated patch that prefix local symbols with __ for more safety.
They appear in the symtab as local so it is not strictly necessary but one is
never too cautious. Being local, they also do not generate any PLT entry.
They appear only because the jumps are from one section to another
(whi
> From: Jeff Law [mailto:l...@redhat.com]
> Sent: Tuesday, April 28, 2015 12:27 AM
> To: Thomas Preud'homme; 'Eric Botcazou'
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH, combine] Try REG_EQUAL for nonzero_bits
>
> On 04/27/2015 04:26 AM, Thomas Pr
> From: Jeff Law [mailto:l...@redhat.com]
> Sent: Tuesday, April 28, 2015 12:27 AM
> OK. No need for heroics -- give it a shot, but don't burn an insane
> amount of time on it. If we can't get to a reasonable testcase, then so
> be it.
Ok, I tried but really didn't managed to create a testcase.
Ping?
Best regards,
Thomas
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Thomas Preud'homme
> Sent: Monday, March 16, 2015 8:39 PM
> To: 'Steven Bosscher'
> Cc: GCC Patches; Eric Botca
targetting Cortex-M0,
Cortex-M3 and whatever default core for ARMv7-a with vfpv3-d16 FPU).
ChangeLog entry is as follows:
*** gcc/testsuite/ChangeLog ***
2015-05-04 Thomas Preud'homme
* gcc.target/arm/pr64616.c: Test dump rather than assembly to work
accross ARM targets.
diff
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Thomas Preud'homme
>
> Based on my understanding of your answer quoted above, I'll commit
> it as is, despite not having been able to come up with a testcase. I'll
> wait
> From: Joseph Myers [mailto:jos...@codesourcery.com]
> Sent: Wednesday, November 12, 2014 10:11 PM
> >
> > This patch modifies the C parser to give an error if:
> > - any variable or function parameter is declared with a float type or
> > a type containing a float (prototype are ignored)
>
> Bu
[Taking over Tony's patch]
Ping?
Best regards,
Thomas
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Tony Wang
> Sent: Thursday, August 21, 2014 7:15 AM
> To: gcc-patches@gcc.gnu.org
> Subject: [PATCH 1/3,ARM,libgcc]Code
[Taking over Tony's patch]
Ping?
Best regards,
Thomas
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Tony Wang
> Sent: Thursday, August 21, 2014 7:15 AM
> To: gcc-patches@gcc.gnu.org
> Subject: [PATCH 2/3,ARM,libgcc]Code
[Taking over Tony's patch]
Ping?
Best regards,
Thomas
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Tony Wang
> Sent: Thursday, August 21, 2014 7:15 AM
> To: gcc-patches@gcc.gnu.org
> Subject: [PATCH 3/3,ARM,libgcc]Code
copy of
the function.
This patch adds an extra parameter to skip this check and only consider the
constraints and tries to pick a register in the preferred class.
ChangeLog entry is as follows:
2014-11-14 Thomas Preud'homme
* regrename.c (find_best_rename_reg):
> From: Richard Biener [mailto:richard.guent...@gmail.com]
> Sent: Monday, November 17, 2014 12:47 PM
>
> Hmm. I am a little bit concerned about the malloc traffic generated here.
> So why not use a vec, get rid of the ->next pointer and
> use a hash_map to associate the stmt with
> an index int
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Tony Wang
>
>
> Hi all,
>
> The bug is reported at
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56846, and it’s about the
> problem that
> when exception handler is involved in the function, then
> _U
Ping?
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Thomas Preud'homme
> Sent: Wednesday, November 19, 2014 6:00 PM
> To: Tony Wang; gcc-patches@gcc.gnu.org; d...@debian.org; aph-
> g...@littl
Thanks. Ccing release manager for their opinion.
Best regards,
Thomas
> -Original Message-
> From: Jonathan Wakely [mailto:jwak...@redhat.com]
> Sent: Wednesday, November 26, 2014 5:33 PM
> To: Thomas Preud'homme
> Cc: Tony Wang; gcc-patches@gcc.gnu.org; d...@
> -Original Message-
> From: Richard Biener [mailto:rguent...@suse.de]
> Sent: Thursday, November 27, 2014 9:57 AM
> To: Ramana Radhakrishnan
> Cc: Thomas Preud'homme; 'Jonathan Wakely'; Jakub Jelinek; Tony Wang;
> gcc-patches@gcc.gnu.org; d...@debian.org
an opening parenthesis, rather than 2+ space or
anything else than a single space (which also was redundant).
With the change, above lines are now not warned about but other incorrect lines
are still reported.
ChangeLog entry is as follows:
*** contrib/ChangeLog ***
2014-11-28 Thomas P
fined and order of
problems in df->problems_in_order[].
ChangeLog entry is as follows:
2015-02-12 Thomas Preud'homme
* df-core.c (df_finish_pass): Iterate over df->problems_by_index[] and
use df_remove_problem rather than manually removing problems, living
h
> From: Bernhard Reutner-Fischer [mailto:rep.dot@gmail.com]
> Sent: Saturday, February 28, 2015 4:00 AM
> > use df_remove_problem rather than manually removing problems,
> living
>
> leaving
Indeed. Please find updated changelog below:
2015-03-03 Thomas Preud'ho
bruary 17, 2015 4:07 PM
> To: Thomas Preud'homme
> Cc: Ramana Radhakrishnan; gcc-patches; Richard Biener; Jakub Jelinek
> Subject: Re: [PATCH, ARM] Fix PR64453: live high register not saved in
> function prolog with -Os
>
> On Fri, Jan 23, 2015 at 8:23 AM, Thomas Pre
1 - 100 of 279 matches
Mail list logo
