On 03/14/2017 05:22 PM, Bernd Schmidt wrote:
This triggered a kernel miscompilation with an old (4.8 I think) aarch64
toolchain.
Here's the reloads for the insn where things go wrong:
Reloads for insn # 210
Reload 0: reload_in (DI) = (reg/v/f:DI 80 [ pgdata ])
GENERAL_REGS, RELOAD_FOR_I
Hi Kelvin,
On Tue, Mar 14, 2017 at 03:06:13PM -0600, Kelvin Nilsen wrote:
> 2017-03-14 Kelvin Nilsen
>
> PR target/79963
> * config/rs6000/altivec.h (vec_all_ne): Under __cplusplus++ and
It is spelled __cplusplus__.
> __POWER9_VECTOR__ #ifdef control, change template defini
2017-03-13 16:33 GMT+03:00 Martin Liška :
> On 03/13/2017 02:07 PM, Richard Biener wrote:
>> No, that can't happen. I said that for example for
>>
>> struct S { ... } s;
>> foo (s);
>>
>> pass_by_reference may be true but on gimple you see a struct s as
>> actual argument. I'm not sure
>> what ch
Successfully bootstrapped®rtested on x86_64-pc-linux-gnu.
OK for trunk? (either now in stage 4, or for next stage1?)
gcc/ChangeLog:
PR translation/80001
* omp-offload.c (oacc_loop_fixed_partitions): Make diagnostics
more amenable to translation.
(oacc_loop_auto_par
PR c++/80014 reports an issue where no caret is printed when issuing an
error for this bogus code:
!typeid(void);
Root cause is that we're not setting up the location for the cp_expr for
the typeid expression, so that
!typeid(void)
has start == caret at the '!', but finish == UNKNOWN_LOCATION,
PR c++/80016 reports an issue with bizarre underlined range
for a complicated expression.
The root cause for the incorrect *starting* location of that range
is that alignof and sizeof expressions currently have
start == finish == caret at the opening parenthesis of the
expression.
This patch fixe
On 03/14/2017 02:53 PM, Richard Kenner wrote:
The GCC manual uses "cannot" in most places (280 lines) but there
are a few instances of "can't" (33 lines).
The attached patch replaces the informal "can't" with the former
for consistency.
In my opinion, this is the wrong direction. Contractions
On 03/14/2017 04:01 PM, Thomas Koenig wrote:
> Hello world,
>
> well, here is the third attempt at fixing the second part of the PR.
> Glancing over the source, I think there are quite a few places where
> we currently issue a runtime error which we could replace by an
> assert, but that's somethi
On 03/01/2017 04:36 AM, JonY wrote:
Patch OK?
ChangeLog:
* unwind-seh.c: Suppress warnings for RtlUnwindEx() calls.
You know this stuff better than anyone else working with GCC. If you
think this is the right thing to do for the SEH code, go for it.
jeff
On 03/13/2017 06:33 PM, Martin Sebor wrote:
The output of a floating point directive whose precision is
specified by an asterisk with an argument that's in a range
that includes both negative and positive values less than
six may include between zero and six fractional digits plus
a decimal point
Our current version of zlib has a bug where zlib has an unsatisfied
reference to _wopen on Cygnwin.
This is a bug in the upstream zlib and is being discussed there. This
patch (from Yaakov Selkowitz) works around the problem and we'll carry
it as a local change until upstream decides on the
Hi James,
>> My reason for asking is that the instruction fusion implemented in LLVM
>> ( lib/Target/AArch64/AArch64MacroFusion.cpp::shouldScheduleAdjacent )
Sorry. There seems to be some confusion in the branch instructions.
The branch should be conditional for ALU_BRANCH fusion.
Please find at
101 - 112 of 112 matches
Mail list logo
