On Wed, Oct 28, 2015 at 01:26:31PM -0700, Nathan Sidwell wrote:
> looking at the next thing to merge, I stumbled on code in lower_omp_target
> that appears at least confused.
>
> we have:
> if (offloaded || data_region)
> { A }
> else if (data_region)
> new_body = tgt_body;
> if (of
This avoids introducing undefined overflow by not folding
unsigned conditional negation to ABS_EXPR. IMHO we want a
well-defined ABS_EXPR with unsigned result at some point, but that
also needs target support (or auditing at least if we want to keep
the existing abs expanders).
Bootstrapped and
Hi!
On Mon, 3 Aug 2015 10:30:49 -0400, Nathan Sidwell wrote:
> I've committed this patch to gomp4. The existing implementation of
> firstprivate
> presumes the existence of memory at the CTA level. This patch does away with
> that, treating firstprivate as thread-private variables initialize
On Wed, Oct 28, 2015 at 08:19:19PM +0300, Alexander Monakov wrote:
>
>
> On Wed, 21 Oct 2015, Jakub Jelinek wrote:
>
> > On Wed, Oct 21, 2015 at 12:16:35PM +0300, Alexander Monakov wrote:
> > > > Of course that doesn't help the thread-limit-2.c testcase.
> > >
> > > Why not?
> >
> > Because th
On Wed, Oct 28, 2015 at 12:16:04PM +0300, Kirill Yukhin wrote:
> Bootstrapped. Regtested. Is it ok for trunk?
>
>
> gcc/
> * omp-low.c (pass_omp_simd_clone::gate): If target allows - call
> without additional conditions.
> * doc/extend.texi (simd): Document new attribute.
Hi!
On Wed, 28 Oct 2015 08:30:56 -0700, Cesar Philippidis
wrote:
> On 10/28/2015 04:00 AM, Thomas Schwinge wrote:
> > On Tue, 27 Oct 2015 11:36:10 -0700, Cesar Philippidis
> > wrote:
> >> This patch contains the following:
> >>
> >> * C front end changes from trunk:
> >> https://gcc.gnu.
Hi!
On Thu, 29 Oct 2015 09:56:18 +0100, I wrote:
> On Wed, 28 Oct 2015 08:30:56 -0700, Cesar Philippidis
> wrote:
> > On 10/28/2015 04:00 AM, Thomas Schwinge wrote:
> > > On Tue, 27 Oct 2015 11:36:10 -0700, Cesar Philippidis
> > > wrote:
> > > With...
> > >
> > >> --- /dev/null
> > >> +++ b/
Hi,
On arm*-*-eabi*, arm*-*-symbianelf*, arm*-*-rtems* targets,
crtfastmath.o is not part of $extra_parts, which means that it is not
built, even though the make build rule is present via the inclusion of
t-crtfm.
The impact is that the link fails when using -ffast-math.
The attached patch adds
On 29/10/15 01:47, H.J. Lu wrote:
> On Wed, Oct 28, 2015 at 6:21 PM, Bernd Schmidt wrote:
>> On 10/29/2015 02:14 AM, H.J. Lu wrote:
>>>
>>> On Wed, Oct 28, 2015 at 6:11 PM, Bernd Schmidt
>>> wrote:
On 10/29/2015 02:10 AM, H.J. Lu wrote:
>
>
> On Wed, Oct 28, 2015 at 5:23 P
On Tue, 27 Oct 2015, Joseph Myers wrote:
> On Tue, 27 Oct 2015, Richard Biener wrote:
>
> > When factoring a*b + a*c to (b + c)*a we have to guard against the
> > case of a == 0 as after the factoring b + c might overflow in that
> > case. Fixed by doing the addition in an unsigned type if requi
On 10/28/2015 04:23 PM, Richard Biener wrote:
> On Tue, Oct 27, 2015 at 4:30 PM, Martin Liška wrote:
>> On 10/27/2015 03:49 PM, Richard Biener wrote:
>>> On Tue, Oct 27, 2015 at 1:36 PM, Martin Liška wrote:
On 10/26/2015 02:48 PM, Richard Biener wrote:
> On Thu, Oct 22, 2015 at 1:02 PM,
On Thu, Oct 29, 2015 at 9:25 AM, Christophe Lyon
wrote:
> Hi,
>
> On arm*-*-eabi*, arm*-*-symbianelf*, arm*-*-rtems* targets,
> crtfastmath.o is not part of $extra_parts, which means that it is not
> built, even though the make build rule is present via the inclusion of
> t-crtfm.
>
> The impact i
[ quote-pasted from
https://gcc.gnu.org/ml/gcc-patches/2011-10/msg00464.html ]
CAST_RESTRICT based disambiguation unfortunately isn't reliable,
e.g. to store a non-restrict pointer into a restricted field,
we add a non-useless cast to restricted pointer in the gimplifier,
and while we don't con
On 23/10/15 13:34, H.J. Lu wrote:
> On Fri, Oct 23, 2015 at 4:54 AM, Marcus Shawcroft
> wrote:
>> Hi,
>>
>> This patch breaks the distinction between build and host. For example
>> consider a configure along these lines:
>>
>> ./configure --host=aarch64-none-linux-gnu
>> --target=aarch64-none-linu
Hi,
adjusting at the same time TREE_TYPE of the already built decl, avoids
ICEing during error recovery in merge_types for this kind of snippet.
Tested x86_64-linux.
Thanks,
Paolo.
/cp
2015-10-29 Paolo Carlini
PR c++/67845
* decl.c (grokfndecl
Hi!
This patch adds support for uniform linear step in addition to
constant linear step, where the step is the value passed in some
integral (or reference to integral) argument.
The vectorizer part of this isn't ready yet, but that will be just an
optimization rather than part of the ABI.
Regtes
On Wed, 28 Oct 2015, Tom de Vries wrote:
> On 28/10/15 16:35, Richard Biener wrote:
> > On Tue, 27 Oct 2015, Tom de Vries wrote:
> >
> > > On 27/10/15 13:24, Tom de Vries wrote:
> > > > Thinking it over a bit more, I realized the constraint handling started
> > > > to be messy. I've reworked the
On 10/28/2015 08:29 PM, Alexander Monakov wrote:
Anything wrong with the simple fix: pick an integer type with the largest size
dividing the original struct type size?
Try it and run it through the testsuite.
Bernd
On Thu, Oct 29, 2015 at 4:00 AM, Richard Earnshaw
wrote:
> On 23/10/15 13:34, H.J. Lu wrote:
>> On Fri, Oct 23, 2015 at 4:54 AM, Marcus Shawcroft
>> wrote:
>>> Hi,
>>>
>>> This patch breaks the distinction between build and host. For example
>>> consider a configure along these lines:
>>>
>>> ./c
> > The recent patches on trunk to gfc_trans_allocate have fixed PR67933.
> > I have added a testcase, which has been committed as revision 229452.
>
> This test case fails at runtime on powerpc64le-linux-gnu. …
This should be fixed after revision r229503.
Dominique
On Thu, Oct 29, 2015 at 4:39 AM, Jan Hubicka wrote:
>> > Added and comitted now.
>>
>> Thanks. Now on to the wrong code issues. :-)
>>
>> Up to the change, the useless_type_conversion_p predicate was relying on
>> structural equivalence via the TYPE_CANONICAL check, now it only looks at the
>> ou
On Thu, Oct 29, 2015 at 12:22 PM, Richard Biener
wrote:
> On Thu, Oct 29, 2015 at 4:39 AM, Jan Hubicka wrote:
>>> > Added and comitted now.
>>>
>>> Thanks. Now on to the wrong code issues. :-)
>>>
>>> Up to the change, the useless_type_conversion_p predicate was relying on
>>> structural equival
On Thu, Oct 29, 2015 at 12:31 PM, Richard Biener
wrote:
> On Thu, Oct 29, 2015 at 12:22 PM, Richard Biener
> wrote:
>> On Thu, Oct 29, 2015 at 4:39 AM, Jan Hubicka wrote:
> Added and comitted now.
Thanks. Now on to the wrong code issues. :-)
Up to the change, the useles
On Thu, 29 Oct 2015, Jakub Jelinek wrote:
> > rather provide a dummy 'usleep' under #ifdef __nvptx__. WDYT?
>
> Such ifdefs aren't really easily possible in OpenMP right now, the
> preprocessing is done with the host compiler only, you'd need to arrange for
> usleep being defined only in the PTX
On Thu, Oct 29, 2015 at 11:38 AM, Tom de Vries wrote:
> [ quote-pasted from https://gcc.gnu.org/ml/gcc-patches/2011-10/msg00464.html
> ]
>
>> CAST_RESTRICT based disambiguation unfortunately isn't reliable,
>> e.g. to store a non-restrict pointer into a restricted field,
>> we add a non-useless ca
On 23/10/15 16:41, H.J. Lu wrote:
> On Fri, Oct 23, 2015 at 7:23 AM, Marcus Shawcroft
> wrote:
>> On 23 October 2015 at 13:34, H.J. Lu wrote:
>>> On Fri, Oct 23, 2015 at 4:54 AM, Marcus Shawcroft
>>> wrote:
Hi,
This patch breaks the distinction between build and host. For example
On 29/10/15 12:13, Richard Biener wrote:
On Wed, 28 Oct 2015, Tom de Vries wrote:
>On 28/10/15 16:35, Richard Biener wrote:
> >On Tue, 27 Oct 2015, Tom de Vries wrote:
> >
> > >On 27/10/15 13:24, Tom de Vries wrote:
> > > >Thinking it over a bit more, I realized the constraint handling start
On Thu, Oct 29, 2015 at 5:05 AM, Richard Earnshaw
wrote:
> On 23/10/15 16:41, H.J. Lu wrote:
>> On Fri, Oct 23, 2015 at 7:23 AM, Marcus Shawcroft
>> wrote:
>>> On 23 October 2015 at 13:34, H.J. Lu wrote:
On Fri, Oct 23, 2015 at 4:54 AM, Marcus Shawcroft
wrote:
> Hi,
>
> Th
OK.
Jason
On Thu, 2015-10-29 at 12:18 +0100, Dominique d'Humières wrote:
> > > The recent patches on trunk to gfc_trans_allocate have fixed PR67933.
> > > I have added a testcase, which has been committed as revision 229452.
> >
> > This test case fails at runtime on powerpc64le-linux-gnu. …
> This should b
On 28 Oct 22:37, Ilya Enkovich wrote:
> Seems the problem occurs in this check in expand_vector_operations_1:
>
> /* A scalar operation pretending to be a vector one. */
> if (VECTOR_BOOLEAN_TYPE_P (type)
> && !VECTOR_MODE_P (TYPE_MODE (type))
> && TYPE_MODE (type) != BLKmode)
>
On Thu, 29 Oct 2015, Tom de Vries wrote:
> On 29/10/15 12:13, Richard Biener wrote:
> > On Wed, 28 Oct 2015, Tom de Vries wrote:
> >
> > > >On 28/10/15 16:35, Richard Biener wrote:
> > > > > >On Tue, 27 Oct 2015, Tom de Vries wrote:
> > > > > >
> > > > > > > >On 27/10/15 13:24, Tom de Vries wrote
On Thu, Oct 29, 2015 at 10:49 AM, Martin Liška wrote:
> On 10/28/2015 04:23 PM, Richard Biener wrote:
>> On Tue, Oct 27, 2015 at 4:30 PM, Martin Liška wrote:
>>> On 10/27/2015 03:49 PM, Richard Biener wrote:
On Tue, Oct 27, 2015 at 1:36 PM, Martin Liška wrote:
> On 10/26/2015 02:48 PM,
Ping:
https://gcc.gnu.org/ml/gcc-patches/2015-10/msg02393.html
On Fri, Oct 23 2015, Andreas Arnez wrote:
> After parsing an unconditional "while"- or "for"-loop, the C front-end
> generates a backward-goto statement and implicitly sets its location to
> the current input_location. But in some
Hi Uros,
As per your comments in
https://gcc.gnu.org/ml/gcc-patches/2015-09/msg02326.html please find the patch
that also adds changes to libgcc.
It was bootstrapped and regressed tested on x86_64.
Ok for trunk?
Change logs
gcc/ChangeLog
2015-10-29 Venkataramanan Kumar
* config
On Mon, Oct 26, 2015 at 6:50 PM, Jeff Law wrote:
> On 10/12/2015 05:35 PM, Evgeny Stupachenko wrote:
>>
>> Hi All,
>>
>> Here is a new version of patch (attached).
>> Bootstrap and make check are in progress (all new tests passed).
>>
>> New test case g++.dg/ext/mvc4.C fails with ICE, when options
Hi,
This patches powerpc fails for c-c++-common/torture/vector-compare-1.c test.
The problem is that vector comparison lowering produces vector of 0s and 1s
instead of 0s and -1s. It doesn't matter if it usage is also lowered (like
happens on ARM and i386 with -mno-sse) byt on powerpc we may
On 28 October 2015 at 10:07, Kyrill Tkachov wrote:
> Hi all,
>
> This RTL checking error occurs on aarch64 in aarch_accumulator_forwarding
> when processing an msubsi insn
> with subregs:
> (insn 15 14 16 3 (set (reg/v:SI 78 [ i ])
> (minus:SI (subreg:SI (reg/v:DI 76 [ aul ]) 0)
>
Hi Marcus,
On 29/10/15 13:46, Marcus Shawcroft wrote:
On 28 October 2015 at 10:07, Kyrill Tkachov wrote:
Hi all,
This RTL checking error occurs on aarch64 in aarch_accumulator_forwarding
when processing an msubsi insn
with subregs:
(insn 15 14 16 3 (set (reg/v:SI 78 [ i ])
(minus:SI
On 29 October 2015 at 13:50, Kyrill Tkachov wrote:
>>> Ok for trunk?
>>
>> rtl.h exposes reg_or_subregno() already doesn't that do what we need here?
>
>
> reg_or_subregno assumes that what it's passed is REG or a SUBREG.
> It will ICE on any other rtx. Here I want to strip the subreg if it is
>
Hi!
On Tue, Oct 27, 2015 at 06:31:41PM -0400, Michael Meissner wrote:
> Index: gcc/testsuite/gcc.target/powerpc/float128-1.c
> ===
> --- gcc/testsuite/gcc.target/powerpc/float128-1.c (revision 0)
> +++ gcc/testsuite/gcc.target/pow
In gomp-4_0-branch, we've tried to consolidate the parsing all of the
clauses of the form
foo (int-expression)
into a single c*_parser_omp_positive_int_clause function. At the time,
such clauses included num_gangs, num_workers, vector_length and
num_threads. Looking at OpenMP 4.5, there are add
This avoids simplifying 2 * (a * (__INT_MAX__/2 + 1))
to a * INT_MIN which introduces undefined overflow for a == -1.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2015-10-29 Richard Biener
PR middle-end/68142
* fold-const.c (extract_muldiv_1): Avoid
On 29/10/15 14:00, Marcus Shawcroft wrote:
On 29 October 2015 at 13:50, Kyrill Tkachov wrote:
Ok for trunk?
rtl.h exposes reg_or_subregno() already doesn't that do what we need here?
reg_or_subregno assumes that what it's passed is REG or a SUBREG.
It will ICE on any other rtx. Here I want
On 29 October 2015 at 11:07, Ramana Radhakrishnan
wrote:
> On Thu, Oct 29, 2015 at 9:25 AM, Christophe Lyon
> wrote:
>> Hi,
>>
>> On arm*-*-eabi*, arm*-*-symbianelf*, arm*-*-rtems* targets,
>> crtfastmath.o is not part of $extra_parts, which means that it is not
>> built, even though the make bui
On 10/23/2015 11:14 AM, Andreas Arnez wrote:
This patch adds a new parameter to c_finish_loop that expclitly
specifies the location to be used for the loop iteration. All calls to
c_finish_loop are adjusted accordingly.
I think the general principle of this is probably ok.
+ bool is_braced
On Fri, Oct 23, 2015 at 1:26 PM, Michael Meissner
wrote:
> This patch is the rs6000.h changes. It makes the IEEE 128-bit floating point
> type that can go in vector registers a 'vector' type, so that the address code
> in rs6000.c that determines whether to use VSX addressing works. In addition,
On Fri, Oct 23, 2015 at 1:36 PM, Michael Meissner
wrote:
> This patch allows SUBREG's for the reg_or_indexed_operand, which is used when
> you have an integral value in a float/vector register, and you want to move
> the
> value (either via direct move on power8, or via store).
>
> I have built t
On Thu, Oct 29, 2015 at 2:42 PM, Ilya Enkovich wrote:
> Hi,
>
> This patches powerpc fails for c-c++-common/torture/vector-compare-1.c test.
> The problem is that vector comparison lowering produces vector of 0s and 1s
> instead of 0s and -1s. It doesn't matter if it usage is also lowered (lik
On Fri, Oct 23, 2015 at 1:30 PM, Michael Meissner
wrote:
> This patch changes the switch from -mfloat128-software and -mfloat128-none to
> be a binary switch, -mfloat128 and -mno-float128. It also provides some of
> the
> basic setup for IEEE types. It also removes code I had put in a previous
On Fri, Oct 23, 2015 at 1:39 PM, Michael Meissner
wrote:
> This patch prevents the compiler from calling the IEEE 128-bit emulation
> functions with the vector value in both GPRs and vector registers due to the
> fact that the library function did not have a prototype.
>
> I have built the compile
On Fri, Oct 23, 2015 at 1:33 PM, Michael Meissner
wrote:
> This patch defines 3 macros to tell the user whether -mfloat128 is enabled or
> not, and whether long double is IBM extended double or IEEE 128-bit floating
> point.
>
> I have built the compiler with this patch and the previous subpatches
On Fri, Oct 23, 2015 at 1:40 PM, Michael Meissner
wrote:
> This patch sets up all of the emulation functions.
>
> I have built the compiler with this patch and the previous subpatches (1-4).
> I
> have bootstrapped the compiler with all 16 subpatches installed, and there
> were
> no regressions
On Fri, Oct 23, 2015 at 1:45 PM, Michael Meissner
wrote:
> This patch adds support for using 'q' or 'Q' as a suffix for __float128
> constants, which is compatible with the existing x86_64 implmenetation of
> their
> __float128 support.
>
> I have built the compiler with this patch and the previo
On Fri, Oct 23, 2015 at 1:49 PM, Michael Meissner
wrote:
> This patch is part of the support needed to properly swap IEEE 128-bit
> floating
> point on little endian systems. Note, you will need the rs6000.md changes for
> this to become effective.
>
> I have built the compiler with this patch a
On Fri, Oct 23, 2015 at 1:47 PM, Michael Meissner
wrote:
> This patch is the new patch from the last submission. It sets up a hook so
> that
> the compiler will not allow IBM extended double and IEEE 128-bit floating
> point
> to intermix in a binary expression without using an explicit conversi
On Fri, Oct 23, 2015 at 1:43 PM, Michael Meissner
wrote:
> This patch updates to use the unordered comparison function for IEEE 128-bit
> floating point to mimic the behaviour of SFmode/DFmode using the fcmpu
> instruction.
>
> It also restructures the code to allow a future change to drop in easi
On Fri, Oct 23, 2015 at 1:52 PM, Michael Meissner
wrote:
> This patch changes the mangling for __float128. I came to the conclusion that
> the current code is so tangled, that it would be better to use U10__float128
> rather than "e". However, if it is felt that we should go with "e", I can go
>
On Fri, Oct 23, 2015 at 1:57 PM, Michael Meissner
wrote:
> This patch is the first of two rs6000.md patches to straighten out the IFmode,
> KFmode, and TFmode support. Part of the change is to change the iterator
> names
> to be easier to understand, using IEEE128, IBM128, and FLOAT128 as the
>
On Fri, Oct 23, 2015 at 1:58 PM, Michael Meissner
wrote:
> This patch is the second part to allow TFmode to be IBM extended double or
> IEEE
> 128-bit floating point depending on switches.
>
> I have built the compiler with this patch and the previous subpatches (1-12).
> I have bootstrapped the
On Fri, Oct 23, 2015 at 2:00 PM, Michael Meissner
wrote:
> This patch makes TFmode be fully switchable for comparisons.
>
> I have built the compiler with this patch and the previous subpatches (1-13).
> I have bootstrapped the compiler with all 16 subpatches installed, and there
> were no regress
On Fri, Oct 23, 2015 at 2:01 PM, Michael Meissner
wrote:
> This patch adds the documentation.
>
> I have built the compiler with this patch and the previous subpatches (1-14).
> I have bootstrapped the compiler with all 16 subpatches installed, and there
> were no regressions. Is it ok to install
On 10/29/2015 02:15 PM, Richard Biener wrote:
> On Thu, Oct 29, 2015 at 10:49 AM, Martin Liška wrote:
>> On 10/28/2015 04:23 PM, Richard Biener wrote:
>>> On Tue, Oct 27, 2015 at 4:30 PM, Martin Liška wrote:
On 10/27/2015 03:49 PM, Richard Biener wrote:
> On Tue, Oct 27, 2015 at 1:36 PM,
After
Index: gcc/gimple-fold.c
===
--- gcc/gimple-fold.c (revision 229518)
+++ gcc/gimple-fold.c (working copy)
@@ -398,7 +398,10 @@ fold_gimple_assign (gimple_stmt_iterator
/* If we couldn't fold the RHS, hand over to t
On Fri, Oct 23, 2015 at 2:03 PM, Michael Meissner
wrote:
> This patch adds a test to make sure __float128 are passed and returned like
> vector objects, and not as IBM extended double did.
>
> This is the last subpatch of patch #7. I have bootstrapped the compiler with
> all 16 subpatches install
>
> IMHO it was always wrong/fragile for backends to look at the actual arguments
> to
> decide on the calling convention. The backends should _solely_ rely on
> gimple_call_fntype and its TYPE_ARG_TYPES here.
>
> Of course then there are varargs ... (not sure if we hit this here).
Yep, you ha
Hello,
before we completely forget about it, this fixes the pattern as discussed
around https://gcc.gnu.org/ml/gcc-patches/2015-10/msg01459.html .
Note that, as seen in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68008#c1 , we would sometimes
like to allow a conversion between trunc_div and
>
> Remove the 600k preprocessed headers.
>
> tested on x86_64 with -m32 and -m64, committed.
Ah, thank you! I had shorter testcase but apparently managed to swap it for
original one :(
Honza
>
> Richard.
>
> 2015-10-28 Richard Biener
>
> * g++.dg/torture/pr67600.C: Remove preproce
...which was failing on *-elf. This test is making sure that we narrow
maths calls, e.g. sinh -> sinhf, but we can only do that if we know that
the target has a full c99 libm or if we have other proof that the function
we want to generate is available.
Tested on aarch64-none-elf (where it's skipp
Tested on x86_64-linux-gnu, arm-linux-gnueabi and aarch64-linux-gnu.
Committed as preapproved by Richard B.
Thanks,
Richard
gcc/
* tree-call-cdce.c (shrink_wrap_one_built_in_call): Remove
unnecessary label.
diff --git a/gcc/tree-call-cdce.c b/gcc/tree-call-cdce.c
index 112a325..
shrink_wrap_one_built_in_call had both guard_bb and guard_bb0.
It looks like an earlier version of the pass may have updated
one of the variables in the while loop, but now they're just
two names for the same thing.
Tested on x86_64-linux-gnu, aarch64-linux-gnu and arm-linux-gnueabi.
Committed as
On Thu, Oct 29, 2015 at 4:06 PM, Marc Glisse wrote:
> Hello,
>
> before we completely forget about it, this fixes the pattern as discussed
> around https://gcc.gnu.org/ml/gcc-patches/2015-10/msg01459.html .
>
> Note that, as seen in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68008#c1
> , we woul
On Thu, Oct 29, 2015 at 4:12 PM, Richard Sandiford
wrote:
> ...which was failing on *-elf. This test is making sure that we narrow
> maths calls, e.g. sinh -> sinhf, but we can only do that if we know that
> the target has a full c99 libm or if we have other proof that the function
> we want to g
On Thu, Oct 29, 2015 at 4:02 PM, Jan Hubicka wrote:
>>
>> IMHO it was always wrong/fragile for backends to look at the actual
>> arguments to
>> decide on the calling convention. The backends should _solely_ rely on
>> gimple_call_fntype and its TYPE_ARG_TYPES here.
>>
>> Of course then there ar
On 10/29/2015 04:30 PM, Richard Sandiford wrote:
Make sure that REAL_MODE_FORMAT aborts if it is passed an invalid mode,
rather than stepping beyond the bounds of an array. It turned out that
some code was passing non-float modes to the real.h routines.
gcc/
* real.h (REAL_MODE_FORMAT
fixed-value.c was passing a fixed-point mode to the floating-point
real_2expN routine. That didn't cause a problem in practice because
all real_2expN did was check for decimal float modes, but it triggered
a failure with an upcoming patch.
Tested on x86_64-linux-gnu, arm-linux-gnueabi and aarch64
Make sure that REAL_MODE_FORMAT aborts if it is passed an invalid mode,
rather than stepping beyond the bounds of an array. It turned out that
some code was passing non-float modes to the real.h routines.
Tested on x86_64-linux-gnu, arm-linux-gnueabi and aarch64-linux-gnu.
OK to install?
Thanks,
On Thu, Jun 4, 2015 at 2:16 PM, Renlin Li wrote:
> Ping ~
>
> Can somebody review it? Thank you!
>
> Regards,
> Renlin Li
>
>
> On 16/04/15 10:32, Renlin Li wrote:
>>
>> Ping~
>>
>> Regards,
>> Renlin Li
>>
>> On 16/04/15 10:09, wrote:
>>>
>>> Ping~
>>> Anybody has time to review it?
>>>
>>>
>>> R
On 10/29/2015 04:28 PM, Richard Sandiford wrote:
* fixed-value.c (check_real_for_fixed_mode, fixed_from_string)
(fixed_to_decimal, fixed_convert_from_real)
(real_convert_from_fixed): Fix mode arguments to real_2expN.
Passing VOIDmode rather than the real mode is a bit of
Yo!
As promised, here is the work implementing a new API for the task
scheduler, rewriting the scheduler to fit into this new API, and
implementing the task priorities that are in OpenMP > 4.1. There are
also lots of cleanups and documentation.
For the record, task priorities allow a priori
> On Thu, Oct 29, 2015 at 4:02 PM, Jan Hubicka wrote:
> >>
> >> IMHO it was always wrong/fragile for backends to look at the actual
> >> arguments to
> >> decide on the calling convention. The backends should _solely_ rely on
> >> gimple_call_fntype and its TYPE_ARG_TYPES here.
> >>
> >> Of cour
On 28/10/15 17:45, Kyrill Tkachov wrote:
On 28/10/15 17:23, Christophe Lyon wrote:
Hi Kyrill,
Hi Christophe,
On 26 October 2015 at 12:52, Kyrill Tkachov wrote:
On 26/10/15 11:28, Bernd Schmidt wrote:
On 10/26/2015 12:12 PM, Bernd Schmidt wrote:
But isn't that balanced by the fact tha
Hi,
The text for -fdump-rtl- is a little misleading about how much you can
derive about pass ordering from the numbers on the dumps. This patch tries
to update the text to clarify that (most of the time) you can quite happily
derive execution order from these pass numbers.
While I'm there I've f
Most real.h routines used machine modes to specify the format of
an operation and converted that to a float_format * internally.
Some also had alternative versions that accepted a float_format *.
In an upcoming patch it seemed more convenient for the callers
I was adding to use float_format direct
Hi,
Consider testcase:
...
int __attribute__((noinline, noclone))
foo (int *__restrict__ a, int *__restrict__ b)
{
*a = 1;
*b = 2;
}
int __attribute__((noinline, noclone))
bar (int *a, int *b)
{
foo (a, b);
}
...
Using this patch we have this diff in the pta dumpfile:
...
@@ -24,7 +24,7 @
Bernd Schmidt writes:
> On 10/29/2015 04:28 PM, Richard Sandiford wrote:
>> * fixed-value.c (check_real_for_fixed_mode, fixed_from_string)
>> (fixed_to_decimal, fixed_convert_from_real)
>> (real_convert_from_fixed): Fix mode arguments to real_2expN.
>
> Passing VOIDmode rather than
Hi all,
An arm-none-eabi build with RTL checking and --with-cpu=cortex-a9 fails because
cortex_a9_sched_adjust_cost tries to access the SET_DEST of a PARALLEL.
The correct thing to do is to call single_set on dep, which will return a
simple SET
that we can take the SET_DEST of or NULL if there's
On 29/10/15 14:12, Richard Biener wrote:
On Thu, 29 Oct 2015, Tom de Vries wrote:
>On 29/10/15 12:13, Richard Biener wrote:
> >On Wed, 28 Oct 2015, Tom de Vries wrote:
> >
> > > >On 28/10/15 16:35, Richard Biener wrote:
> > > > > >On Tue, 27 Oct 2015, Tom de Vries wrote:
> > > > > >
> > > >
On Wed, 2015-10-28 at 12:38 +0100, Bernd Schmidt wrote:
> On 10/27/2015 08:48 PM, David Malcolm wrote:
> > The following patch kit adds a unit tests framework for gcc,
> > as a new subdirectory below gcc/testsuite.
>
> So, as a general comment I think this would be a very good thing to
> have, an
As as been noted in the past, the old jump threader's support for
threading across a loop backedge introduces significant complexity. The
most serious complexity is the need to handle processing statements a
second time (as we come around the top of the loop). This requires
invalidation su
On October 29, 2015 4:28:05 PM GMT+01:00, Richard Sandiford
wrote:
>fixed-value.c was passing a fixed-point mode to the floating-point
>real_2expN routine. That didn't cause a problem in practice because
>all real_2expN did was check for decimal float modes, but it triggered
>a failure with an u
On 10/29/2015 09:52 AM, James Greenhalgh wrote:
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 76fdc31..148f063 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -6665,17 +6665,19 @@ Says to make debugging dumps during compilation at
times specified by
@var{letters}.
On October 29, 2015 4:53:59 PM GMT+01:00, Richard Sandiford
wrote:
>Most real.h routines used machine modes to specify the format of
>an operation and converted that to a float_format * internally.
>Some also had alternative versions that accepted a float_format *.
>
>In an upcoming patch it seem
On October 29, 2015 4:33:17 PM GMT+01:00, Bernd Schmidt
wrote:
>On 10/29/2015 04:30 PM, Richard Sandiford wrote:
>> Make sure that REAL_MODE_FORMAT aborts if it is passed an invalid
>mode,
>> rather than stepping beyond the bounds of an array. It turned out
>that
>> some code was passing non-flo
On 10/18/2015 05:55 PM, Mikhail Maltsev wrote:
On 10/06/2015 03:56 PM, Richard Biener wrote:
The generators should simply unconditionally check (not in generated
files, of course).
And the generated code parts should use flag_checking.
Richard.
genautomata has some macros similar to tree chec
Attempting to bootstrap gcc with -Wmisleading-indentation enabled I ran
into a few failures where the indentation, although bad, was arguably
not misleading.
In regrename.c:scan_rtx_address:
1308 case PRE_MODIFY:
1309/* If the target doesn't claim to handle autoinc, this must be
tree-nested.c has this code:
2333 for (c = gimple_omp_taskreg_clauses (stmt);
2334 c;
2335 c = OMP_CLAUSE_CHAIN (c))
2336if ((OMP_CLAUSE_CODE (c) == OMP_CLAUSE_FIRSTPRIVATE
2337 || OMP_CLAUSE_CODE (c) ==
The following patches:
* tweak -Wmisleading-indentation to suppress a kind of false
positive that occurred in three places in gcc's source
tree, and
* fix the two remaining truly misleadingly-indented places
where the warning fires
* adds -Wmisleading-indentation to -Wall
Boot
tree-ssa-loop-unswitch.c has this bad indentation at line 452:
449if (dump_file && (dump_flags & TDF_DETAILS))
450 fprintf (dump_file, ";; Not unswitching, loop is not expected"
451 " to iterate\n");
452 return false;
which leads to this war
Richard Biener writes:
> On October 29, 2015 4:33:17 PM GMT+01:00, Bernd Schmidt
> wrote:
>>On 10/29/2015 04:30 PM, Richard Sandiford wrote:
>>> Make sure that REAL_MODE_FORMAT aborts if it is passed an invalid
>>mode,
>>> rather than stepping beyond the bounds of an array. It turned out
>>that
1 - 100 of 194 matches
Mail list logo
