On Sat, Sep 30, 2017 at 06:12:39PM -0700, H.J. Lu wrote:
> Since size of "void *" is 4 bytes for x32, check if __x86_64__ is defined
> by $CC, instead of
>
> if test x$ac_cv_sizeof_void_p = x8; then
>
> to decide wether anitizer_linux_x86_64.lo should be used.
>
> I am testing this on i686 and x
On Tue, Oct 3, 2017 at 3:33 PM, Bernd Edlinger
wrote:
> Hi!
>
> I have implemented a warning -Wcast-function-type that analyzes
> type casts which change the function signatures.
>
> I would consider function pointers with different result type
> invalid, also if both function types have a non-nul
On Tue, Oct 3, 2017 at 1:08 PM, Nathan Sidwell wrote:
> [non-c++ people on CC, there's a reason ...]
>
> This patch adds a new warning, concerning unnecessary parentheses on a
> declaration. For instance:
>prettyprinter (pp);
> That's a declaration of a pp variable of type prettyprinter -- no
On 04/10/17 18:21 +0200, François Dumont wrote:
On 03/10/2017 16:20, Jonathan Wakely wrote:
Doesn't the modified test PASS anyway, even without changing how _M_c
is used?
No it doesn't because the first check for eof capture the 'a' char
which is never reseted so after string construction it
On 10/04/2017 08:53 AM, Eric Botcazou wrote:
>> This seems like a SPARC target problem to me -- essentially it's
>> claiming a higher STACK_BOUNDARY than it really has.
>
> No, it is not, I can guarantee you that the stack pointer is always aligned
> to
> 64-bit boundaries on SPARC, otherwise al
On Wed, 2017-10-04 at 16:41 +0100, Richard Earnshaw (lists) wrote:
> On 02/10/17 10:05, Sudi Das wrote:
> >
> > 2017-10-02 Sudakshina Das
> >
> > * config/aarch64/aarch64-protos.h (enum simd_immediate_check): New
> > check type
> > for aarch64_simd_valid_immediate.
> > (aarch64_out
Hi,
The Power8 swap optimization pass contains a mini-pass to replace certain
patterns prior to swap optimization proper. In order for this not to
distort the dataflow information for swap optimization, we should process
all the deferred rescans between the two passes. Currently that is not
done
Hello world,
the attached patch sets the implicit ASYNCHRONPUS according to F2008,
9.6.2.5:
# If a variable is used in an asynchronous data transfer statement as
# • an item in an input/output list,
# • a group object in a namelist, or
# • a SIZE= specifier
# the base object of the data-ref is i
On 9/30/17, H.J. Lu wrote:
> Since size of "void *" is 4 bytes for x32, check if __x86_64__ is defined
> by $CC, instead of
>
> if test x$ac_cv_sizeof_void_p = x8; then
>
> to decide wether anitizer_linux_x86_64.lo should be used.
>
> I am testing this on i686 and x86-64. OK for trunk and GCC 7 b
On 10/4/17, Jakub Jelinek wrote:
> Hi!
>
> The following patch tweaks the TImode vector shifts similarly
> to the earlier vector shift patch, so that for shifts by immediate
> we can accept a memory input. Additionally, it removes the vec_shl_*
I prefer 2 patches, a separate patch to drop vec_sh
On 09/28/2017 08:25 AM, Nathan Sidwell wrote:
On 09/24/2017 06:03 PM, Martin Sebor wrote:
r253041 enhanced type checking for alias and ifunc attributes to
detect declarations of incompatible aliases, or ifunc resolvers
that return pointers to functions of an incompatible type. More
extensive te
Hi!
While working on the previous patch, I've noticed we have quite a few
seemingly useless isa attributes (first I've noticed isa attribute
which had one value for all alternatives, which IMHO should just
been done in insn condition instead).
fma_avx512f isa is only used on insns that have TARGE
Hi!
The following patch tweaks the TImode vector shifts similarly
to the earlier vector shift patch, so that for shifts by immediate
we can accept a memory input. Additionally, it removes the vec_shl_*
expander, because the middle-end has dropped that a few years ago,
and merges the left and righ
Hi!
EVEX encoded vector shifts by immediate allow memory operand as input.
We handle this right for the sra patterns by having 3 distinct
define_insns, one TARGET_AVX512VL with masking, where the non-masked
insn names start with *, that have (=v,v,v) and (=v,vm,N) alternatives
and nonimmediate_ope
On 3 October 2017 at 14:10, Jeff Law wrote:
> On 10/03/2017 03:00 PM, Marc Glisse wrote:
>> On Tue, 3 Oct 2017, Jakub Jelinek wrote:
>>
>>> On Tue, Oct 03, 2017 at 12:54:39PM -0700, Prathamesh Kulkarni wrote:
Hi,
This follow-up patch implements the patterns mentioned in $subject.
Bo
On Wed, Oct 04, 2017 at 11:05:23AM +0200, Martin Liška wrote:
> Following patch adds support for optimizing out unnecessary UBSAN_PTR checks.
> It handles separately positive and negative offsets, zero offset is ignored.
> Apart from that, we utilize get_inner_reference for local and global
> vari
On Wed, Oct 4, 2017 at 1:52 PM, Nathan Sidwell wrote:
> The builtin type machinery is one of the places were we push decls into ::
> under not-their-name.
>
> There's no real reason for this, and the fix is simple -- create a new
> TYPE_DECL if we use a name from the ridpointer table. I took the
The builtin type machinery is one of the places were we push decls into
:: under not-their-name.
There's no real reason for this, and the fix is simple -- create a new
TYPE_DECL if we use a name from the ridpointer table. I took the
opportunity of reordering record_builtin_type, which was a s
As described in
https://gcc.gnu.org/ml/gcc-patches/2017-10/msg00122.html, I found a few
places where declarations were excessively parenthesized. These seem to
be the uncontroversial cases, so fixing thusly.
Applying to trunk.
nathan
--
Nathan Sidwell
2017-10-04 Nathan Sidwell
* toplev.
To deal with changes in the ABI that affected manglings, we like pushing
decls into :: under their mangled names. This is one of the 3 places we
push decls under something not their DECL_NAME, and causes the namespace
binding map to not be a simple hash table of DECLs.
It also can give rise t
On Thu, Jul 27, 2017 at 06:49:01PM +0100, James Greenhalgh wrote:
>
> On Mon, Jun 12, 2017 at 02:44:40PM +0100, James Greenhalgh wrote:
> > [Sorry for the re-send. I spotted that the attributes were not right for the
> > new pattern I was adding. The change between this and the first version
> >
vec_unpacks_hi_v4sf/vec_unpacks_lo_v4sf expand vec_mergeh and vec_mergel
patterns also for z13 with V4SF modes so the patterns should better
accept this. Fixed by changing the mode iterator to V_128_NOSINGLE
which accepts V4SF unconditionally.
Committed to mainline.
gcc/ChangeLog:
2017-10-04 A
On 03/10/2017 16:20, Jonathan Wakely wrote:
On 02/10/17 07:43 +0200, François Dumont wrote:
On 28/09/2017 23:56, Jonathan Wakely wrote:
On 28/09/17 21:59 +0200, François Dumont wrote:
The current istreambuf_iterator implementation capture the current
streambuf state each time it is tested fo
On 10/04/2017 11:29 AM, Jason Merrill wrote:
On Wed, Oct 4, 2017 at 10:12 AM, Nathan Sidwell wrote:
In answering a question about passing non-trivial types through ..., I
discovered a misleading comment. It is NOT just like a value parm, because
we don't locally copy it.
Hmm, I think the err
On 02/10/17 10:05, Sudi Das wrote:
>
> Hi Richard
>
> Thanks, I have made the change to the patch.
>
>
> 2017-10-02 Sudakshina Das
>
> * config/aarch64/aarch64-protos.h (enum simd_immediate_check): New
> check type
> for aarch64_simd_valid_immediate.
> (aarch64_output_simd
On Wed, Aug 9, 2017 at 3:20 PM, Jason Merrill wrote:
> In this testcase, when building up an extra version of N to refer to
> when instantiating the generic lambda, we were mistakenly replacing
> the 'auto' with a template argument for the generic lambda.
>
> Tested x86_64-pc-linux-gnu, applying t
OK.
On Wed, Oct 4, 2017 at 8:50 AM, Paolo Carlini wrote:
> Hi,
>
> Andrew noticed that the reason we reject entities like inline-asm or GNU's
> statement-expressions in the lambda body is simply that we don't set the
> parser->in_function_body flag. Thus the below, which appears to work
> perfect
On Wed, Oct 4, 2017 at 10:12 AM, Nathan Sidwell wrote:
> In answering a question about passing non-trivial types through ..., I
> discovered a misleading comment. It is NOT just like a value parm, because
> we don't locally copy it.
Hmm, I think the error is in the behavior, not the comment. :)
Hi Tom!
On Tue, 3 Oct 2017 10:56:59 +0200, Tom de Vries wrote:
> On 09/27/2017 03:46 PM, Thomas Schwinge wrote:
> > On Mon, 25 Sep 2017 16:57:52 +0200, Tom de Vries
> > wrote:
> >> currently for a GOACC_REDUCTION internal fn call we print:
> >> ...
> >> sum_5 = GOACC_REDUCTION (SETUP, _3, 0
> We have now had 5 days of no builds for a major target, which is a huge
> inconvenience. So I don't think it is reasonable to wait any longer.
well, to put things in perspective, you broke the SPARC compiler about one
month ago and have done anything AFAIK since then to repair the breakage so..
> This seems like a SPARC target problem to me -- essentially it's
> claiming a higher STACK_BOUNDARY than it really has.
No, it is not, I can guarantee you that the stack pointer is always aligned to
64-bit boundaries on SPARC, otherwise all hell would break loose...
> Presumably there's a good
On Wed, Oct 04, 2017 at 10:44:11AM -0400, Jason Merrill wrote:
> > 3) A couple of places do:
> >T (name // line break to avoid wrap
> > [LONGEXPR][OTHERLONGEXPR]);
> >
> > The parens aid the editor's formatter. The patch removes the parens, but I
> > can see there may be disagreement. I
On Tue, Oct 3, 2017 at 1:08 PM, Nathan Sidwell wrote:
> [non-c++ people on CC, there's a reason ...]
>
> This patch adds a new warning, concerning unnecessary parentheses on a
> declaration. For instance:
>prettyprinter (pp);
> That's a declaration of a pp variable of type prettyprinter -- no
The following patch completely re-does PHI handling during
code-generation. PHI handling is currently responsible for 99% of
all code-generation issues. With the patch the number of code-generation
issues in SPEC 2k6 decreases from 180 to 5, similar adjustments happen
to the testsuite - only gf
In answering a question about passing non-trivial types through ..., I
discovered a misleading comment. It is NOT just like a value parm,
because we don't locally copy it.
class X { ..,non-poddy... };
void Foo (X, ...);
void bin (X &p)
{
Foo (p, p);
}
Only the first arg to Foo goes via a cop
On Wed, Oct 04, 2017 at 02:12:11PM +0100, Ramana Radhakrishnan wrote:
> On Wed, Oct 4, 2017 at 12:01 PM, Richard Sandiford
> wrote:
> > Wilco Dijkstra writes:
> >> Christophe Lyon wrote:
> >>
> >>> FWIW, I confirm that this patch fixes the build failure I reported at:
> >>> https://gcc.gnu.org/ml
This patch implements a new API entrypoint:
/* Build a vector rvalue from an array of elements.
"vec_type" should be a vector type, created using gcc_jit_type_get_vector.
This API entrypoint was added in LIBGCCJIT_ABI_10; you can test for its
presence using
#ifdef LIBGCCJIT_HAVE_gc
On Wed, Oct 4, 2017 at 2:39 PM, Alexander Monakov wrote:
> On Wed, 4 Oct 2017, Ramana Radhakrishnan wrote:
>> However we need a scheduler maintainer or global reviewer to please
>> help review this patch or help come up with an alternative patch. A
>> primary platform broken for 5 days with a comm
On Wed, 4 Oct 2017, Ramana Radhakrishnan wrote:
> However we need a scheduler maintainer or global reviewer to please
> help review this patch or help come up with an alternative patch. A
> primary platform broken for 5 days with a commit and no public
> response from the original poster is really
Hi,
I've recently committed a follow-up fix for PR71727 for -mstrict-align
on aarch64 (r253242).
I think it would be appropriate to apply it to gcc-7-branch. The patch
from trunk applies cleanly to gcc-7-branch.
Although the original bug was reported against 4.9.4, 5.3.1, 6.1.0,
Naveen's patch wa
On Wed, Oct 04, 2017 at 01:24:15PM +, Wilco Dijkstra wrote:
> Well my understanding was that it is OK to fix a bootstrap failure. I believe
> my
> patch is trivial since it mostly removes redundant code. Also I took Jakub's
> review as an OK as there were no technical objections. However since
Richard Sandiford wrote:
>
> I don't think it's reasonable to commit this as obvious. You said
> yourself in the covering message that "it doesn't at all restore
> the original behaviour since we no longer compare the base address".
> So even with the bootstrap failure, I think the patch needed re
On Wed, Oct 4, 2017 at 12:01 PM, Richard Sandiford
wrote:
> Wilco Dijkstra writes:
>> Christophe Lyon wrote:
>>
>>> FWIW, I confirm that this patch fixes the build failure I reported at:
>>> https://gcc.gnu.org/ml/gcc-patches/2017-09/msg01980.html
>>
>> Thanks, now committed as r253399.
>
> I don
Hi!
On Mon, Oct 02, 2017 at 07:52:50PM -0400, Michael Meissner wrote:
> Whoops, I forgot to attach the patch.
Heh. The rs6000 parts are of course okay (trivial / obvious, but maybe
you are waiting for an ack).
Thanks,
Segher
Hi,
Andrew noticed that the reason we reject entities like inline-asm or
GNU's statement-expressions in the lambda body is simply that we don't
set the parser->in_function_body flag. Thus the below, which appears to
work perfectly for that. Tested x86_64-linux.
Thanks, Paolo.
//
On 10/04/2017 04:13 AM, Jakub Jelinek wrote:
Hi!
If a function has auto return value that is deducted to return function
pointer (or pointer array?), we pretty print it as e.g.
auto N::foo)(int)
The problem is that if show_return we use fndecl_declared_return_type (t)
for the type prefix, but TR
On Wed, Oct 4, 2017 at 10:33 AM, Jakub Jelinek wrote:
> Hi!
>
> Most AVX* instructions have the same insn name between VEX and EVEX
> encoded insns and whether it is EVEX or VEX encoded is determined by
> the operands by the assembler (if there is masking/broadcast, or
> %[xy]mm16+ operands are pr
Hi!
On Wed, 4 Oct 2017 10:01:10 +0200, Jakub Jelinek wrote:
> This patch propagates attributes, including opt and target nodes, from
> the containing function to the OMP/OACC outlined region functions.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk.
Hmm, in your t
Wilco Dijkstra writes:
> Christophe Lyon wrote:
>
>> FWIW, I confirm that this patch fixes the build failure I reported at:
>> https://gcc.gnu.org/ml/gcc-patches/2017-09/msg01980.html
>
> Thanks, now committed as r253399.
I don't think it's reasonable to commit this as obvious. You said
yourself
build_range_check explicitly allows LOW and HIGH to be a different type
from EXP, so we need to use w::to_widest when comparing a value based on
HIGH with a value based on EXP's type.
Tested on powerpc64le-linux-gnu and installed as obvious.
Richard
2017-10-04 Richard Sandiford
gcc/
Committed as revision 253400.
Thanks for the review and the test.
Paul
On 1 October 2017 at 14:24, Thomas Koenig wrote:
> Hi Paul,
>
>> The attached patch fixes the PR and most of the remaining, if not all,
>> problems associated with deferred string length targets in the
>> associate construct
Christophe Lyon wrote:
> FWIW, I confirm that this patch fixes the build failure I reported at:
> https://gcc.gnu.org/ml/gcc-patches/2017-09/msg01980.html
Thanks, now committed as r253399.
Wilco
On Sun, Oct 01, 2017 at 02:07:57AM +0100, Michael Collison wrote:
> Sorry. Here is the patch.
I think this needs a small amount fo rework in iterators.md - the names
you've used don't follow conventions in that file (e.g. "V" normally has
something to do with vectors) so could do with patching up.
Hello.
Following patch adds support for optimizing out unnecessary UBSAN_PTR checks.
It handles separately positive and negative offsets, zero offset is ignored.
Apart from that, we utilize get_inner_reference for local and global variables,
that also helps to reduce some.
Some numbers:
1) postg
Hi,
I found 3 test-cases in libgomp/testsuite/libgomp.oacc-c-c++-common that
do a 32-bit floating point reduction on integer values and verify the
result using an equality test, while the result is larger than the
largest integer that can be exactly represented in 32-bit fp (16777216).
This
Hello Ramana,
> On Oct 4, 2017, at 10:21 , Ramana Radhakrishnan
> wrote:
> This is OK .
Great :-)
> Sorry about the delay - I've been traveling a bit.
No worries, thanks for the review!
With Kind Regards,
Olivier
Hi!
Most AVX* instructions have the same insn name between VEX and EVEX
encoded insns and whether it is EVEX or VEX encoded is determined by
the operands by the assembler (if there is masking/broadcast, or
%[xy]mm16+ operands are present, or when using 512-bit vectors).
This is not the case for th
On Thu, Aug 3, 2017 at 10:02 AM, Olivier Hainque wrote:
> Hello,
>
> Activating dwarf2 based eh for real on VxWorks6 (patch to come) triggers a
> libgcc build failure, where most functions resorting to __builtin_eh_return
> fail this check from maybe_record_trace_start in dwarf2cfi.c:
>
> /*
On 3 October 2017 at 18:34, Wilco Dijkstra wrote:
> r253236 broke AArch64 bootstrap. Earlier revision r253071 changed scheduling
> behaviour on AArch64 as autopref scheduling no longer checks the base.
>
> This patch fixes the bootstrap failure and cleans up autopref scheduling.
> The code is grea
Hi!
If a function has auto return value that is deducted to return function
pointer (or pointer array?), we pretty print it as e.g.
auto N::foo)(int)
The problem is that if show_return we use fndecl_declared_return_type (t)
for the type prefix, but TREE_TYPE (fntype) for the type suffix,
and if th
Hi!
This patch propagates attributes, including opt and target nodes, from
the containing function to the OMP/OACC outlined region functions.
Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk.
2017-10-04 Jakub Jelinek
PR tree-optimization/82374
* omp-l
Hello,
Ping #3 for https://gcc.gnu.org/ml/gcc-patches/2017-09/msg00017.html
please.
Took the liberty to cc a maintainer.
Thanks much in advance!
With Kind Regards,
Olivier
> On Sep 25, 2017, at 08:49 , Olivier Hainque wrote:
>
> Hello,
>
> Ping #2 for https://gcc.gnu.org/ml/gcc-patches/20
Hello,
Ping # 2 for https://gcc.gnu.org/ml/gcc-patches/2017-08/msg00271.html
* config/arm/arm.c (arm_set_return_address): Use MEM_VOLATILE_P
on the target mem instead of RTX_FRAME_RELATED_P on the insn to
prevent DSE.
(thumb_set_return_address): Likewise.
This one fix
Hello,
Ping # 3 for https://gcc.gnu.org/ml/gcc-patches/2017-08/msg01783.html
please.
Took the liberty to cc a maintainer.
Thanks much in advance!
With Kind Regards,
Olivier
> On Sep 25, 2017, at 08:51 , Olivier Hainque wrote:
>
> Hello,
>
> Ping #2 for https://gcc.gnu.org/ml/gcc-patches/2
While my last change involving signed types was correct it wasn't optimal.
We can avoid the modulo constraints if the conversion is widening
(thus all values fit in the new type).
Bootstrapped and tested on x86_64-unknown-linux-gnu, ok?
Thanks,
Richard.
2017-10-04 Richard Biener
* g
uOn Tue, 3 Oct 2017, Rainer Orth wrote:
> Hi Richard,
>
> > What ISL Versions are affected?
>
> it's 0.18.
>
> >>Besides, there's
> >>
> >>+UNRESOLVED: gfortran.dg/graphite/pr42393-1.f90 -O
> >>scan-tree-dump-times graphite "code generation error" 1
> >>
> >>for both 32 and 64-bit. The lo
66 matches
Mail list logo
