On Thu, 9 Mar 2017, Jakub Jelinek wrote:
> 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 te
On Thu, 9 Mar 2017, Jakub Jelinek wrote:
> 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
Hi Christophe,
The testcase is not expected to output anything. So only the exit code should
be set to zero. I called libgfortrans exit-function to quit the program. I am
not aware that I need to do more. Happy for any insight what goes wrong. There
are also issues on hpux, but I think they hav
On 9 March 2017 at 09:45, Andre Vehreschild wrote:
> 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
Hi James,
> The whitespace in various places in this patch is inconsistent with the
> whitespace around the modified line. For example:
Fixed the whitespace.
>> So this patch isn't OK without fixes for the models
>> in cortex-a53.md and exynos-m1.md
Thanks for pointing out the missing cores in
Hi James,
>> You need to do this for all cores which might be affected by this change,
>> i.e. all those which model neon_mul_d_long.
Thanks for pointing out the missing cores in patch.
Added the support as per your comments.
Please find attached the modified patch and let us know
if its okay fo
On Thu, Mar 09, 2017 at 12:45:29PM -0500, David Malcolm wrote:
> 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
On Thu, Mar 09, 2017 at 12:45:28PM -0500, David Malcolm wrote:
> 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
On Thu, Mar 09, 2017 at 12:45:26PM -0500, David Malcolm wrote:
> 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.
>
On Thu, Mar 09, 2017 at 12:45:25PM -0500, David Malcolm wrote:
> 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 diag
On Thu, Mar 09, 2017 at 12:45:23PM -0500, David Malcolm wrote:
> 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 --gi
The patch below addresses some pretty-printer issues. More precisely,
it handles 6 types of expressions that weren't handled before:
a) EXACT_DIV_EXPR, RDIV_EXPR,
b) LROTATE_EXPR, RROTATE_EXPR,
c) MAX_EXPR, MIN_EXPR.
Right now we print for the testcase below:
#'exact_div_expr' not suppor
It's been a while and I wanted to post a status update. My new tests
needed a few fix-ups to work on Cygwin, but they pass.
As for the rest, it turns out that running the testsuite on Cygwin is a
vertable nightmare. The tests are NOT even correct because they load
the shared libs (dlls) that
On 03/09/2017 10:45 AM, David Malcolm wrote:
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 transla
On 03/09/2017 10:45 AM, David Malcolm wrote:
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
On 03/09/2017 03:35 PM, Segher Boessenkool wrote:
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 (op
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
> >
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
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 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!
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
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
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
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 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
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 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
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
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
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
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 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 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
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 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
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
* 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
* 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
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
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
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
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 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
> 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-
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
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!
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
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',
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
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 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
>
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 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
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 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
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 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
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_
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
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
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
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 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
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)
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
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 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 +++
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
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 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
> > >
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 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 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
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 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
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
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 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
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 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
>
> Ok for mainline with that fixed.
>
> Thanks.
> Rainer
>
Committed as r246004.
Thanks,
Toma
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
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
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
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
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
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/
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
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
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
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 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
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
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 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,
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 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 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 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 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
1 - 100 of 116 matches
Mail list logo
