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.
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,
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 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
OK.
Jason
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
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
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
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,
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
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
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 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
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
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
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)
> +++
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
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
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
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
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
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 [
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
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
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 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
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
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
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
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 *.
>
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
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
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
...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
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
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
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 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
>
> 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
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
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
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?
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
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
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
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
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
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
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
> 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.
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,
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
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
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
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
>
> 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
>
> *
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
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
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
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
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
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: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
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
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,
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:
>
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
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
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
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
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
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 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
LRA wants to replace SCRATCH registers with real registers. It should
not do that with (mem:BLK (scratch)), which is special, not really a
scratch register.
I don't know if this patch handles this in the best place to handle it;
I don't even know if it is really correct. It does solve the
> Yes. This is not necessary. However that way we'll have the following
> code in dispatcher:
> cmpl$6, __cpu_model+4(%rip)
> sete%al
> movzbl %al, %eax
> testl %eax, %eax
> jle .L16
> movl$foo.target_clone.1, %eax
> I think it is
On Thu, Oct 29, 2015 at 12:52 PM, Segher Boessenkool
wrote:
> The PIC reg (r30) needs to be saved whenever the prologue sets it up,
> not just if it is used elsewhere in the function. Without this patch
> the prologue for such a function will modify r30 without saving
On 10/29/2015 10:55 AM, James Greenhalgh wrote:
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 76fdc31..5549f17 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 Thu, 2015-10-29 at 13:35 -0400, Patrick Palka wrote:
> On Thu, Oct 29, 2015 at 12:49 PM, David Malcolm wrote:
> > Attempting to bootstrap gcc with -Wmisleading-indentation enabled I ran
> > into a few failures where the indentation, although bad, was arguably
> > not
Our documentation describes -Wall as enabling "all the warnings about
constructions that some users consider questionable, and that are easy to avoid
(or modify to prevent the warning), even in conjunction with macros."
I believe that -Wmisleading-indentation meets these criteria, and is
likely
On October 29, 2015 4:37:08 PM GMT+01:00, Ramana Radhakrishnan
wrote:
>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:
>>>
On 10/29/2015 10:49 AM, David Malcolm wrote:
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
On 10/29/2015 10:49 AM, David Malcolm wrote:
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");
On Thu, Oct 29, 2015 at 1:35 PM, Patrick Palka wrote:
> On Thu, Oct 29, 2015 at 12:49 PM, David Malcolm wrote:
>> Attempting to bootstrap gcc with -Wmisleading-indentation enabled I ran
>> into a few failures where the indentation, although bad, was
On Thu, Oct 29, 2015 at 10:33:48AM -0400, David Edelsohn wrote:
> 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
> >
Hi!
This patch fixes an ICE, where c_finish_omp_atomic is called on
a template for diagnostics purposes because the expressions aren't type
dependent, but still calling save_expr on C++ trees is harmful
(e.g. SCOPE_REF contains a type as one of the arguments, rather than
expression).
2015-10-29
On Thu, Oct 29, 2015 at 1:50 PM, Mike Stump wrote:
> On Oct 29, 2015, at 10:42 AM, Patrick Palka wrote:
>> However we should definitely not warn on
>>
>>if (foo)
>> bar ();
>>
>> {
>>baz ();
>> }
>>
>> Since that is valid
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
This patch changes the type descriptor hash and equal functions from C
code pointers to Go func values. This permits them to be set to a Go
function closure. This is in preparation for the Go 1.5, so that we
can use a closure for the hash/equal functions returned by the new
reflect.ArrayOf
On 10/29/2015 03:25 AM, Ramana Radhakrishnan wrote:
Actually this is even worse than I thought because it sounds like you're
saying you knowingly checked something in while being aware it would break
another port.
Only when -fno-plt was used.
So, that's a target independent feature in GCC !
On 10/29/2015 10:49 AM, David Malcolm wrote:
Our documentation describes -Wall as enabling "all the warnings about
constructions that some users consider questionable, and that are easy to avoid
(or modify to prevent the warning), even in conjunction with macros."
I believe that
On Oct 29, 2015, at 10:56 AM, Patrick Palka wrote:
> On Thu, Oct 29, 2015 at 1:50 PM, Mike Stump wrote:
>> On Oct 29, 2015, at 10:42 AM, Patrick Palka wrote:
>>> However we should definitely not warn on
>>>
>>> if (foo)
>>>
The gc Go library added a zero field to type descriptors for use by
maps. It was added to gccgo in a library updated a while back,
although gccgo never used it. The gc library has since dropped it.
This patch removes it from gccgo. This is in preparation for an
update to the Go 1.5 library.
This patch supports the sized variants of operator delete.
Tested on x86_64-linux.
Is this OK or is it completely sufficient to just call non-sized
operator delete from libitm even if the program has a sized delete? (If
the latter is the case, I would just remove the special handling for
that
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
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
I noticed a comment typo in this file while using grep to look for
other stuff. The typo is easy to fix.
I tried running neon-testgen.ml to verify, but it is apparently no
longer valid ocaml, as it doesn't work with the ocamlc 4.01.0 I have
on Ubuntu 14.04. I get a syntax error. Someone who
The PIC reg (r30) needs to be saved whenever the prologue sets it up,
not just if it is used elsewhere in the function. Without this patch
the prologue for such a function will modify r30 without saving it
first, leading to disaster back in its callers. This happened in the
testsuite for -m32
On 10/28/2015 07:14 PM, 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 PM, Jeff Law wrote:
So I'll ask again, why did you commit a patch which you clearly knew
1 - 100 of 192 matches
Mail list logo