On Wed, 8 Mar 2017, Jakub Jelinek wrote:
> Hi!
>
> As reported, we were using often completely bogus access sizes for
> atomic builtins, where the access size should be determined purely by their
> _{1,2,4,8,16} suffix, not by whatever type the passed pointer points to,
> pointer conversions are
On Tue, Mar 7, 2017 at 7:52 PM, Jakub Jelinek wrote:
> Hi!
>
> As mentioned in the PR, 6 intrinsics were only defined in section
> guarded with #ifdef __OPTIMIZE__ (unnecessarily, because the intrinsics
> don't have any immediate argument that must be constant) and without
> #defines for -O0.
>
>
On Tue, Mar 7, 2017 at 7:54 PM, Jakub Jelinek wrote:
> Hi!
>
> I've preprocessed x86intrin.h with -O0 and -O2, both with -E -dD,
> and gathered all _mm starting inline function names at column zero
> and #define _mm macro names and compared them.
> This revealed that 64 intrinsics have similar bug
Hi Christophe,
you are right, that error message does not help a bit. Can you manually compile
and execute the testcase? Does it print "ERROR STOP: This statement should not
be reached."?
If not what does
fail_image_2 && echo "yes" || echo "no"
print? It should be "yes"
- Andre
On Wed, 8 Ma
Hi,
Here's a patch to disable the test for BCLRI.d optimization for level -O0.
OK for trunk?
Changelog:
2017-03-09 Prachi Godbole
gcc/testsuite/
* gcc.target/mips/msa-bclri.c: Skip the test for -O0.
Index: testsuite/gcc.target/mips/msa-bclri.c
=
Hi all,
This patch fixes the vec_select errors found by Jakub's genrecog validation
improvements:
../../gcc/config/aarch64/aarch64-simd.md:79:1: DImode of first vec_select
operand is not a vector mode
../../gcc/config/aarch64/aarch64-simd.md:79:1: DFmode of first vec_select
operand is not a ve
Hi!
Similarly to https://gcc.gnu.org/ml/gcc-patches/2009-09/msg01161.html
the C FE gets wrong the location of DW_TAG_enumeral_type if there is a
forward declaration. If we e.g. have a variable that is first declared
extern and then defined, we emit DW_TAG_variable with the location of the
first d
Prachi Godbole writes:
> 2017-03-09 Prachi Godbole
>
> gcc/testsuite/
> * gcc.target/mips/msa-bclri.c: Skip the test for -O0.
>
>
> Index: testsuite/gcc.target/mips/msa-bclri.c
> ===
> --- testsuite/gcc.target/mips/msa-bcl
On 03/08/2017 09:03 AM, Eric Botcazou wrote:
>> I prepared quite obvious fix for that and tested make check -k
>> RUNTESTFLAGS="dg.exp=dump-ada-spec-*" on x86_64-linux-gnu.
>
> Thanks for spotting and fixing it. Please put the fix on the 6 branch too.
>
Yes, I'll add the patch when I'll test pe
PING^1:
On 03/02/2017 06:15 PM, marxin wrote:
> gcc/ChangeLog:
>
> 2017-03-06 Martin Liska
>
> PR tree-optimization/79631
> * tree-chkp-opt.c (chkp_is_constant_addr): Call
> tree_int_cst_sign_bit just for INTEGER constants.
>
> gcc/testsuite/ChangeLog:
>
> 2017-03-06 Mart
Rainer Orth writes:
> > g++.dg/lto/pr69589_0.C is currently failing for mips-mti-elf with the
> following error:
> >
> > xg++: error: unrecognized command line option '-rdynamic'
> >
> > However, it passes just fine for mips-mti-linux-gnu.
> > I think that we should skip this test for mips-mti-elf
Committed as r245995 with dg-skip-if comment change.
Prachi
-Original Message-
From: Matthew Fortune
Sent: Thursday, March 9, 2017 2:59 PM
To: Prachi Godbole; gcc-patches@gcc.gnu.org
Cc: Moore, Catherine
Subject: RE: [PATCH][MIPS]MSA AND.d optimization to generate BCLRI.d
Prachi Godbole
Ping?
Best regards,
Thomas
On 02/03/17 14:51, Thomas Preudhomme wrote:
Hi,
This patch fixes an assert failure when linking one LTOed object file
having a weak alias with a regular object file containing a strong
definition for that same symbol. The patch is twofold:
+ do not add an alias to
Ping.
On Wed, Mar 01, 2017 at 04:16:56PM +0100, Marek Polacek wrote:
> On Tue, Feb 28, 2017 at 01:12:38PM -1000, Jason Merrill wrote:
> > On Tue, Feb 28, 2017 at 10:10 AM, Marek Polacek wrote:
> > > On Fri, Feb 24, 2017 at 11:11:05AM -0800, Jason Merrill wrote:
> > >> On Fri, Feb 24, 2017 at 8:22
On 08/03/17 17:39, James Greenhalgh wrote:
On Mon, Mar 06, 2017 at 05:09:58AM +, Hurugalawadi, Naveen wrote:
Hi,
Please find attached the patch that adds aes and sha reservations for
Thunderx2t99.
Bootstrapped and Regression tested on aarch64-thunder-linux.
Please review the patch and let
On 03/07/2017 05:21 PM, Jakub Jelinek wrote:
> On Mon, Mar 06, 2017 at 02:07:37PM +0100, marxin wrote:
>> PR target/65705
>> PR target/69804
>> * toplev.c (process_options): Disable -fcheck-pointer-bounds with
>> sanitizers.
>
> I can understand why it is disabled for -fsanitiz
On Thu, Mar 2, 2017 at 6:15 PM, marxin wrote:
> gcc/ChangeLog:
>
> 2017-03-06 Martin Liska
>
> PR tree-optimization/79631
> * tree-chkp-opt.c (chkp_is_constant_addr): Call
> tree_int_cst_sign_bit just for INTEGER constants.
>
> gcc/testsuite/ChangeLog:
>
> 2017-03-06 Ma
On 03/09/2017 11:04 AM, Richard Biener wrote:
> On Thu, Mar 2, 2017 at 6:15 PM, marxin wrote:
>> gcc/ChangeLog:
>>
>> 2017-03-06 Martin Liska
>>
>> PR tree-optimization/79631
>> * tree-chkp-opt.c (chkp_is_constant_addr): Call
>> tree_int_cst_sign_bit just for INTEGER con
On Thu, Mar 09, 2017 at 06:22:33AM +, Hurugalawadi, Naveen wrote:
> Hi James,
>
> Thanks for the review and your comments.
>
> >> I'd need more detail on what types of instruction pairs you
> >> are trying to fuse.
>
> The documentation mentions it as follows:-
> Single uop ALU instruction
On Thu, Mar 09, 2017 at 09:15:05AM +, Kyrill Tkachov wrote:
> Hi all,
>
> This patch fixes the vec_select errors found by Jakub's genrecog validation
> improvements:
> ../../gcc/config/aarch64/aarch64-simd.md:79:1: DImode of first vec_select
> operand is not a vector mode
> ../../gcc/config/
On Thu, Mar 09, 2017 at 10:01:57AM +, Kyrill Tkachov wrote:
>
> On 08/03/17 17:39, James Greenhalgh wrote:
> >On Mon, Mar 06, 2017 at 05:09:58AM +, Hurugalawadi, Naveen wrote:
> >>Hi,
> >>
> >>Please find attached the patch that adds aes and sha reservations for
> >>Thunderx2t99.
> >>
> >>
On Mon, Mar 06, 2017 at 05:09:34AM +, Hurugalawadi, Naveen wrote:
> Hi,
>
> Please find attached the patch that adds "crypto_pmull" for AArch64.
>
> Bootstrapped and Regression tested on aarch64-thunder-linux.
>
> Please review the patch and let us know if its okay for Stage-1?
>
> Thanks,
Thanks Gerald,
JonY: what about the attached patch to document the change of behavior of GCC on
Windows depending on the configure option used?
Best regards,
Thomas
On 04/03/17 14:25, Gerald Pfeifer wrote:
On Thu, 2 Mar 2017, Thomas Preudhomme wrote:
This should be mentioned in the "portin
On Wed, Mar 08, 2017 at 06:09:52PM +, James Greenhalgh wrote:
> On Mon, Mar 06, 2017 at 05:09:44AM +, Hurugalawadi, Naveen wrote:
> > Hi,
> >
> > Please find attached the patch that adds "neon_pairwise_add" &
> > "neon_pairwise_add_qcrypto_pmull" for AArch64.
> >
> > The patch doesn't ch
On Thu, Mar 09, 2017 at 10:51:27AM +, Thomas Preudhomme wrote:
> Thanks Gerald,
>
> JonY: what about the attached patch to document the change of behavior of
> GCC on Windows depending on the configure option used?
GCC 7 has not branched yet, so the change can't be committed anywhere.
It seem
Hi Jakub,
I forgot to mention "ok for stage1?", my bad. JonY said he was queuing the
corresponding changes in GCC for stage1 so I was just trying to have a complete
story. I do not expect to commit this before the actual code change is committed.
Best regards,
Thomas
On 09/03/17 10:58, Jaku
On 03/08/2017 12:00 PM, Richard Biener wrote:
> On Tue, Mar 7, 2017 at 5:01 PM, Martin Liška wrote:
>> On 03/07/2017 03:53 PM, Richard Biener wrote:
>>> On Tue, Mar 7, 2017 at 3:48 PM, Martin Liška wrote:
On 03/07/2017 11:17 AM, Rainer Orth wrote:
> marxin writes:
>
>> diff --gi
On 03/09/2017 11:22 AM, Thomas Preudhomme wrote:
> Hi Jakub,
>
> I forgot to mention "ok for stage1?", my bad. JonY said he was queuing
> the corresponding changes in GCC for stage1 so I was just trying to have
> a complete story. I do not expect to commit this before the actual code
> change is c
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2017-03-09 Richard Biener
PR ipa/79970
* ipa-prop.c (ipa_modify_formal_parameters): Avoid changing
alignment of BLKmode params.
* gcc.dg/torture/pr79970.c: New testcase.
Index: gcc/ipa-pr
Bootstrapped and tested on x86_64-unknown-linux-gnu,
tested with a cross to arm, applied.
Richard.
2017-03-09 Richard Biener
PR middle-end/79971
* gimple-expr.c (useless_type_conversion_p): Preserve
TYPE_SATURATING for fixed-point types.
* gcc.dg/fixed-point/
This patch fixes SESE merging which can sometimes form a region
that is not SE.
Bootstrap/regtest running on x86_64-unknown-linux-gnu.
Richard.
2017-03-09 Richard Biener
PR tree-optimization/79977
* graphite-scop-detection.c (scop_detection::merge_sese):
Handle the c
Hello.
Following patch fixes issue by checking original declaration instead
of instrumentation clone.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Martin
>From 1235ced464fa990eaa4157ea216aeac7e4023b06 Mon Sep 17 00:00:00 2001
From: marxin
Date: T
Hi,
Recently we've put a lot of effort into improving ifcvt to use CSEL on AArch64.
In https://gcc.gnu.org/ml/gcc-patches/2015-11/msg01639.html James determined
the best value for AArch64 code generation. Although this setting is used when
explicitly targeting Cortex cores, it is not otherwise u
A patch in the attachment fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79949
The patch was successfully tested and bootstrapped on x86-64.
Committed as rev. 246003.
Index: ChangeLog
===
--- ChangeLog (revision 246002)
+++ Ch
Hello,
The mainline compiler, configured for powerpc-wrs-vxworks, fails
to handle the simple test below at -O2.
The failure mode looks like:
./gnat1 -Iada/rts opt64_pkg.adb -O2
...
opt64_pkg.adb: In function 'Opt64_Pkg.Encode':
opt64_pkg.adb:14:1: error: alignment of array elements is gr
>
> Ok for mainline with that fixed.
>
> Thanks.
> Rainer
>
Committed as r246004.
Thanks,
Toma
On Thu, Mar 9, 2017 at 4:07 PM, Olivier Hainque wrote:
> Hello,
>
> The mainline compiler, configured for powerpc-wrs-vxworks, fails
> to handle the simple test below at -O2.
>
> The failure mode looks like:
>
> ./gnat1 -Iada/rts opt64_pkg.adb -O2
> ...
> opt64_pkg.adb: In function 'Opt64_Pk
This is a new type for C++17, with no impact on anything in non-C++17
dialects. This is intentionally only defined in and not
.
To keep small I didn't include to get
std::is_integral, I just defined a new helper for std::byte. For GCC 8
stage 1 we might want to refactor this so the list of int
> On 09 Mar 2017, at 16:16, Richard Biener wrote:
>
> I think a simpler fix, doing
>
> type = TYPE_MAIN_VARIANT (type);
>
> should work equally well.
Hmm, indeed. Thanks for the super fast review and suggestion.
You meant that we can do that unconditionally (not only for
types with an alig
Ping!
TIA,
Andreas
On 16.02.17 20:21, Andreas Tobler wrote:
Hi all,
the attached patch adds unwind support for aarch64-*-freebsd*.
John used to catch unwind tests in ada.
So far it bootstraps and I see no regressions.
is this ok for trunk?
TIA,
Andreas
2017-02-16 John Marino
*
On Thu, Mar 09, 2017 at 10:24:43AM +0100, Jakub Jelinek wrote:
> Hi!
>
> Similarly to https://gcc.gnu.org/ml/gcc-patches/2009-09/msg01161.html
> the C FE gets wrong the location of DW_TAG_enumeral_type if there is a
> forward declaration. If we e.g. have a variable that is first declared
> extern
On Thu, Mar 09, 2017 at 04:49:31PM +0100, Marek Polacek wrote:
> On Thu, Mar 09, 2017 at 10:24:43AM +0100, Jakub Jelinek wrote:
> > Hi!
> >
> > Similarly to https://gcc.gnu.org/ml/gcc-patches/2009-09/msg01161.html
> > the C FE gets wrong the location of DW_TAG_enumeral_type if there is a
> > forwa
OK.
On Wed, Mar 1, 2017 at 10:16 AM, Marek Polacek wrote:
> On Tue, Feb 28, 2017 at 01:12:38PM -1000, Jason Merrill wrote:
>> On Tue, Feb 28, 2017 at 10:10 AM, Marek Polacek wrote:
>> > On Fri, Feb 24, 2017 at 11:11:05AM -0800, Jason Merrill wrote:
>> >> On Fri, Feb 24, 2017 at 8:22 AM, Marek Po
On Thu, Mar 9, 2017 at 4:42 PM, Olivier Hainque wrote:
>
>> On 09 Mar 2017, at 16:16, Richard Biener wrote:
>>
>> I think a simpler fix, doing
>>
>> type = TYPE_MAIN_VARIANT (type);
>>
>> should work equally well.
>
> Hmm, indeed. Thanks for the super fast review and suggestion.
>
> You meant t
On Thu, Mar 09, 2017 at 04:57:42PM +0100, Jakub Jelinek wrote:
> On Thu, Mar 09, 2017 at 04:49:31PM +0100, Marek Polacek wrote:
> > On Thu, Mar 09, 2017 at 10:24:43AM +0100, Jakub Jelinek wrote:
> > > Hi!
> > >
> > > Similarly to https://gcc.gnu.org/ml/gcc-patches/2009-09/msg01161.html
> > > the C
On Thu, Mar 09, 2017 at 05:27:33PM +0100, Marek Polacek wrote:
> > That would be just for consistency with finish_struct, right?
>
> Yeah.
>
> > Not sure if we need such consistency, but I don't care that much. The point
> > to put it into start_enum was that we don't really care about the locat
On Thu, Mar 09, 2017 at 05:34:43PM +0100, Jakub Jelinek wrote:
> On Thu, Mar 09, 2017 at 05:27:33PM +0100, Marek Polacek wrote:
> > > That would be just for consistency with finish_struct, right?
> >
> > Yeah.
> >
> > > Not sure if we need such consistency, but I don't care that much. The
> > >
Hi,
Per PR79941, we are folding the vec_mul{e,o}* operations improperly. Those
entries were added to the intrinsics-to-be-folded list where the generic
multiplies should have been instead. Test coverage in place was for the
generic multiplies, and this was missed by my testing.
The mul[eo]* unsig
On Thu, Mar 09, 2017 at 10:52:52AM -0600, Will Schmidt wrote:
> Per PR79941, we are folding the vec_mul{e,o}* operations improperly. Those
> entries were added to the intrinsics-to-be-folded list where the generic
> multiplies should have been instead. Test coverage in place was for the
> generic
gcc/ChangeLog:
PR target/79925
* config/aarch64/aarch64.c (aarch64_validate_mcpu): Quote the
full command-line argument, rather than just "str".
(aarch64_validate_march): Likewise.
(aarch64_validate_mtune): Likewise.
---
gcc/config/aarch64/aarch64.c | 10 +++
Roland Illig [CCed] recently filed numerous issues within our Bugzilla
instance relating to i18n.
In general, the issues look valid to me, so I've attempted to fix some
of them in the following patch kit.
However, we're deep in stage 4 of the development cycle. Looking at
our development plan
gcc/ChangeLog:
PR driver/79875
* opts.c (parse_sanitizer_options): Add missing question mark to
"did you mean" message.
---
gcc/opts.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/opts.c b/gcc/opts.c
index 8274fab..6ea57af 100644
--- a/gcc/opts.c
gcc/ChangeLog:
PR translation/79923
* auto-profile.c (get_combined_location): Convert leading
character of diagnostics to lower case and remove trailing period.
(read_profile): Likewise for various diagnostics.
* config/arm/arm-builtins.c (arm_expand_builtin)
PR translation/79848 requests that uses of "%<%s%>" in diagnostic messages
be simplified to "%qs", presumably to make it easier for translators
to deal with them.
This patch does this for all such strings found in the source tree.
gcc/c-family/ChangeLog:
PR translation/79848
* c-f
PR fortran/79852 reports various Fortran diagnostics that have a trailing
exclamation mark in their messages.
Is there a Fortran-specific convention here?
Otherwise, this patch removes the trailing exclamation marks.
gcc/fortran/ChangeLog:
PR fortran/79852
* bbt.c (insert): Remov
PR target/79926 notes that in:
sorry ("%s instructions aren't allowed in %s service routine",
isa, (cfun->machine->func_type == TYPE_EXCEPTION
? "exception" : "interrupt"));
the text from the second %s won't be translated, but should be.
This patch reworks the dia
xgettext wasn't locating the message:
("...this statement, but the latter is misleadingly indented"
" as if it were guarded by the %qs"),
when building gcc.pot, and so this message was not being translated.
It appears the root cause is the parens around the concatenated
literals
The lxc1-sxc1 tests fundamentally require hard-float to test the
relevant instruction usage. This patch adds -mhard-float to force
it on all configurations.
gcc/testsuite/
* gcc.target/mips/lxc1-sxc1-1.c: Use -mhard-float.
* gcc.target/mips/lxc1-sxc1-2.c: Likewise.
Committed to
2017-03-09 Michael Eager
Correct failures with --enable-checking=yes,rtl.
* config/microblaze/microblaze.c (microblaze_expand_shift):
Replace GET_CODE test with CONST_INT_P and INTVAL test with
test for const0_rtx.
* config/microblaze/microblaze.md (ashlsi3_
On Fri, Mar 03, 2017 at 01:10:18PM -0500, Michael Meissner wrote:
> On January 31st I commited a patch that improves conversion of signed/unsigned
> char/short values to 32-bit and 64-bit floating point on Power9, particularly
> when the values are coming from memory. This adds similar support to
PR bootstrap/79952 identifies a crash that can occur when running
-fself-test.
The root cause is an out-of-bounds memory write in the RTL dump
reader when handling SYMBOL_REFs with SYMBOL_FLAG_HAS_BLOCK_INFO set.
Such SYMBOL_REFs are normally created by varasm.c:create_block_symbol,
which has:
On Tue, Mar 07, 2017 at 03:36:38PM -0600, Will Schmidt wrote:
> Per PR79941, we are folding the vec_mul{e,o}* operations improperly. Those
> entries were added to the intrinsics-to-be-folded list where the generic
> multiplies should have been instead. Test coverage in place was for the
> generic
Jason,
looking at how we implement inline namespaces on the back of strong
using directives, I notice that strong using is much more general. One
can name a target namespace from multple different strong using
directives in different namespaces. (The DECL_NAMESPACE_ASSOCIATIONS is
a list of
On 03/03/17 10:47 -0500, David Edelsohn wrote:
This patch caused a new regression on AIX.
I'm unable to bootstrap on either gcc111 or gcc119 so I can't test
the fix.
- David
FAIL: 17_intro/names.cc (test for excess errors)
Excess errors:
/tmp/GCC/gcc/include-fixed/sys/types.h:600: error: ex
On Thu, Mar 9, 2017 at 2:15 PM, Nathan Sidwell wrote:
> looking at how we implement inline namespaces on the back of strong using
> directives, I notice that strong using is much more general. One can name a
> target namespace from multple different strong using directives in different
> namespac
On Wed, Mar 08, 2017 at 09:47:32AM -0600, Bill Schmidt wrote:
> As noted by Jakub in https://gcc.gnu.org/ml/gcc-patches/2017-03/msg00183.html,
> the PowerPC back end incorrectly uses vec_select with 2 elements for a mode
> that has only one. This is due to faulty mode iterator use: V1TImode was
>
While updating our C++17 features to add the new std::invoke_result
trait I got annoyed with the repetition in std::_Not_fn, as it makes
it hard to check it's defined correctly. Specifically, we need to
repeat the cv-qualifier and ref-qualifiers in multiple places in each
overload.
This introduce
On Thu, Mar 09, 2017 at 12:00:48AM +0100, Marek Polacek wrote:
> We crash on an assert in strip_typedefs, because we find ourselves in a
> scenario where RESULT, the main variant of a struct, was modified in
> finalize_record_size (its TYPE_ALIGN changed), but its variants (T in
> strip_typedefs) w
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the Swedish team of translators. The file is available at:
http://translationproject.org/latest/gcc/sv.po
(This file, 'gcc-7.1-b20170226.sv.po',
Hi!
The following testcase fails on ppc* due to invalid RTL sharing.
The problem is that replace_rtx never copy_rtx or copy_rtx_if_shared
anything, so if i{2,1,0}dest is present in CALL_INSN_FUNCTION_USAGE more
than once, and corresponding i{2,1,0}src is non-shareable RTL, then we ICE.
On the othe
Hi!
get_range_info must be only called on SSA_NAMEs (that don't have
POINTER_TYPE_P type), but the first instance of this pass is before
into ssa so we can see VAR_DECLs in some cases instead of SSA_NAMEs.
There is on the other side no point testing that range_type is non-zero
(== not VR_UNDEFINED
Hi!
As you know, this is mostly your patch, I've just added some comments,
testcase and a small optimization; I believe the fix is right, if next[j]
is constant in addition to val[j] (for both args or op[1-j] is constant),
the loop can have 0(1), 1(2) or infinite iterations, and we can just brute
> Yes, unconditionally.
Here's an adjusted patch, pleasantly simpler indeed
(thanks again for the suggestion).
Test passes fine as well.
Is this one OK ?
Olivier
* tree-switch-conversion (array_value_type): Start by
resetting candidate type to it's main variant.
switch-conv-
On 03/09/2017 03:27 PM, Jason Merrill wrote:
I think I already did:
2017-01-26 Jason Merrill
* name-lookup.c (parse_using_directive): Deprecate strong using.
Cool!
--
Nathan Sidwell
Hello world,
the attached patch fixes a part of PR 79956, where
warnings about maybe uninitialized variables broke
bootstrap-O3 due to -Wmaybe-uninitialized warnings.
I have also attached a compressed version of the patch including the
changes in generated/ in case anybody wants to test, but doe
On Thu, 9 Mar 2017, David Malcolm wrote:
> However, we're deep in stage 4 of the development cycle. Looking at
> our development plan
> https://gcc.gnu.org/develop.html
> it's not clear to me how such changes fit into our schedule: the plan
> seems to make no mention of how i18n and translation
On Thu, 9 Mar 2017, Andreas Tobler wrote:
> Ping!
Why are you pinging this, Andreas? Are you seeking review to
make sure this is appropriate?
>> 2017-02-16 John Marino
>>
>> * config/aarch64/freebsd-unwind.h: New file.
>> * config.host: Add aarch64-*-freebsd unwinder.
I'm asking s
At the WG21 meeting last week we approved P0604R0 which replaces the
error-prone result_of and is_callable APIs
with invoke_result and is_invocable and
is_invocable_r. Only result_of exists in previous
standards, the rest are new for C++17.
This patch replaces the is_callable family with the new
* Claudiu Zissulescu [2017-02-28 16:29:15
+0100]:
> Hi,
>
> This series of two patches fixes a typo in tst instruction, and a faulty mov
> conditional instruction.
>
> Ok to apply?
> Claudiu
Sorry for the delay, both of these look fine.
Thanks,
Andrew
* Claudiu Zissulescu [2017-02-28 16:43:17
+0100]:
> Hi,
>
> This series of two patches adds new ARCv2 code-density instructions to
> our backend (patch 1). And improves the size figures by using section
> anchors and different register allocation order (patch 2).
>
> OK to apply?
> Claudiu
Th
On Thu, Mar 9, 2017 at 6:42 AM, Wilco Dijkstra wrote:
> Hi,
>
> Recently we've put a lot of effort into improving ifcvt to use CSEL on
> AArch64.
> In https://gcc.gnu.org/ml/gcc-patches/2015-11/msg01639.html James determined
> the best value for AArch64 code generation. Although this setting is
On 09.03.17 22:44, Gerald Pfeifer wrote:
On Thu, 9 Mar 2017, Andreas Tobler wrote:
Ping!
Why are you pinging this, Andreas? Are you seeking review to
make sure this is appropriate?
2017-02-16 John Marino
* config/aarch64/freebsd-unwind.h: New file.
* config.host: Add aar
We are crashing left and right with enumerators in attribute nonnull arguments.
Albeit handle_nonnull_attribute calls default_conversion to accept various
integer constants (default_conversion calls scalar_constant_value which can
turn CONST_DECLs into INTEGER_CSTs), it doesn't save the converted r
On Wed, Mar 08, 2017 at 04:29:59PM -0600, Pat Haugen wrote:
> The following patch fixes an "insn does not match its constraints" ICE
> that occurred when copying a VR reg to a GPR when -mno-upper-regs-df is
> in effect. The regclass used for the wi/wj constraints was being
> incorrectly based on TA
On 03/09/2017 01:32 PM, Thomas Koenig wrote:
> Hello world,
>
> the attached patch fixes a part of PR 79956, where
> warnings about maybe uninitialized variables broke
> bootstrap-O3 due to -Wmaybe-uninitialized warnings.
>
> I have also attached a compressed version of the patch including the
>
On Thu, Mar 09, 2017 at 10:06:53PM +0100, Jakub Jelinek wrote:
> On Thu, Mar 09, 2017 at 12:00:48AM +0100, Marek Polacek wrote:
> > We crash on an assert in strip_typedefs, because we find ourselves in a
> > scenario where RESULT, the main variant of a struct, was modified in
> > finalize_record_si
On Thu, 9 Mar 2017, Andreas Tobler wrote:
> Basically yes, but I'm not sure how the planning and the freeze for
> trunk is. This is why ping.
If (since?) this can only affect FreeBSD, or really FreeBSD/aarch64,
you are pretty much at liberty to make such a change.
(We did not formally document
Yep, I just checked in that change.
On Thu, Mar 9, 2017 at 5:32 PM, Marek Polacek wrote:
> On Thu, Mar 09, 2017 at 10:06:53PM +0100, Jakub Jelinek wrote:
>> On Thu, Mar 09, 2017 at 12:00:48AM +0100, Marek Polacek wrote:
>> > We crash on an assert in strip_typedefs, because we find ourselves in a
OK.
On Thu, Mar 9, 2017 at 5:25 PM, Marek Polacek wrote:
> We are crashing left and right with enumerators in attribute nonnull
> arguments.
> Albeit handle_nonnull_attribute calls default_conversion to accept various
> integer constants (default_conversion calls scalar_constant_value which can
On Thu, Mar 09, 2017 at 11:25:49PM +0100, Marek Polacek wrote:
> We are crashing left and right with enumerators in attribute nonnull
> arguments.
> Albeit handle_nonnull_attribute calls default_conversion to accept various
> integer constants (default_conversion calls scalar_constant_value which
Hi,
Section 6.11 of the GCC manual (Additional Floating Types) has been
updated numerous times for this release and has become a little
disorderly. This patch attempts to reorganize the material in this
section to flow more naturally, remove caveats that are no longer
true, and generally avoid co
On Thu, Mar 09, 2017 at 12:45:00PM -0600, Segher Boessenkool wrote:
> On Fri, Mar 03, 2017 at 01:10:18PM -0500, Michael Meissner wrote:
> > On January 31st I commited a patch that improves conversion of
> > signed/unsigned
> > char/short values to 32-bit and 64-bit floating point on Power9,
> > p
On Mar 8, 2017, Richard Biener wrote:
> On Wed, Mar 8, 2017 at 12:58 AM, Alexandre Oliva wrote:
>> Don't let pointer randomization change the order in which we process
>> store chains. This may cause SSA_NAMEs to be released in different
>> order, and if they're reused later, they may cause di
On Thu, Mar 09, 2017 at 05:59:39PM +0100, Jakub Jelinek wrote:
> On Thu, Mar 09, 2017 at 10:52:52AM -0600, Will Schmidt wrote:
> > Per PR79941, we are folding the vec_mul{e,o}* operations improperly. Those
> > entries were added to the intrinsics-to-be-folded list where the generic
> > multiplies s
Hi Will,
On Thu, Mar 09, 2017 at 10:52:52AM -0600, Will Schmidt wrote:
> Per PR79941, we are folding the vec_mul{e,o}* operations improperly. Those
> entries were added to the intrinsics-to-be-folded list where the generic
> multiplies should have been instead. Test coverage in place was for the
Hi!
On Thu, Mar 09, 2017 at 10:18:43AM -0800, Michael Eager wrote:
> --- a/gcc/config/microblaze/microblaze.c
> +++ b/gcc/config/microblaze/microblaze.c
> @@ -3323,10 +3323,10 @@ microblaze_expand_shift (rtx operands[])
> || (GET_CODE (operands[1]) == SUBREG));
>
>/* Shift by ze
On 03/09/2017 08:28 PM, David Malcolm wrote:
The root cause is an out-of-bounds memory write in the RTL dump
reader when handling SYMBOL_REFs with SYMBOL_FLAG_HAS_BLOCK_INFO set.
Such SYMBOL_REFs are normally created by varasm.c:create_block_symbol,
which has:
Hmm, I don't actually recall seei
Hi Jakub,
On Thu, Mar 09, 2017 at 10:12:17PM +0100, Jakub Jelinek wrote:
> The following testcase fails on ppc* due to invalid RTL sharing.
> The problem is that replace_rtx never copy_rtx or copy_rtx_if_shared
> anything, so if i{2,1,0}dest is present in CALL_INSN_FUNCTION_USAGE more
> than once,
On Thu, Mar 09, 2017 at 05:15:40PM -0600, Segher Boessenkool wrote:
> On Thu, Mar 09, 2017 at 05:59:39PM +0100, Jakub Jelinek wrote:
> > On Thu, Mar 09, 2017 at 10:52:52AM -0600, Will Schmidt wrote:
> > > Per PR79941, we are folding the vec_mul{e,o}* operations improperly. Those
> > > entries were
On Thu, Mar 09, 2017 at 07:01:06PM -0500, Michael Meissner wrote:
> > > This looks good to me, but I'll defer the actual review to PowerPC
> > > maintainers. Perhaps there was some hidden reason (xlC compatibility,
> > > whatever) that said that vmuleub etc. should have signed vector arguments
> >
1 - 100 of 116 matches
Mail list logo
