The following fixes PR69907, BB vectorization not properly avoiding
loading excess elements beyond the last scalar access. As seen by
the testsuite adjustments this pessimizes the cases where we'd know
the underlying object is larger, but that's a general issue also
for loop vectorization with ga
On Tue, 23 Feb 2016, Jakub Jelinek wrote:
> Hi!
>
> As mentioned in the PR, the builtin-integral-1.c testcase fails on
> i?86 Solaris. The problem is that on Solaris the dg-add-options c99_runtime
> adds -std=c99, which turns -fexcess-precision=standard, and that on some
> arches changes
> _3
On Tue, 23 Feb 2016, Jakub Jelinek wrote:
> Hi!
>
> When the base of a handled component (BIT_FIELD_REF in the testcase)
> is SSA_NAME which happens to be expanded as some MEM (on the testcase
> it is SSA_NAME set to VIEW_CONVERT_EXPR of an SSA_NAME that has MEM as
> DECL_RTL), expand_expr_real_1
On Mon, 22 Feb 2016, Richard Biener wrote:
>
> The following patch fixes invalid upper bounds recorded for conditonal
> array accesses - it doesn't depend on whether their IV wrap or not
> (and we were unsetting 'reliable' only anyway). In fact conditional
> accesses should be good enough for an
Hi all,
In this PR we get an ICE when the hoist pass ends up creating an
(insn 88 0 0 (set (reg:OI 136)
(const_int 0 [0])) -1
(nil))
instruction. AArch64 doesn't support such an OImode set.
The only OImode set operations that aarch64 supports are load/store-multiple
operations
on v
Hi all,
I'm committing this patch as obvious to fix a typo and a TWS occurrence in
changes.html.
Thanks,
Kyrill
Index: htdocs/gcc-6/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-6/changes.html,v
retrieving revision 1.61
di
2016-02-22 14:50 GMT+03:00 Alan Lawrence :
> On 20/02/16 09:29, Ilya Enkovich wrote:
>>
>> 2016-02-19 20:36 GMT+03:00 Alan Lawrence :
>>>
>>> On 17/11/15 11:49, Ilya Enkovich wrote:
Hi,
Default hook for get_mask_mode is supposed to return integer vector
modes.
Thi
On 19/02/16 15:24, Kyrill Tkachov wrote:
> Hi all,
>
> The atomic_loaddi expander on arm has some issues and can benefit from a
> rewrite to properly
> perform double-word atomic loads on various architecture levels.
>
> Consider the code:
> --
> #include
>
> atomic_ullon
The test gcc.dg/builtins-68.c fails on x86_64-apple-darwin15:
FAIL: gcc.dg/builtins-68.c (test for errors, line 79)
FAIL: gcc.dg/builtins-68.c (test for excess errors)
Excess errors:
/opt/gcc/work/gcc/testsuite/gcc.dg/builtins-68.c:107:40: warning: large integer
implicitly truncated to unsigned
Hi all,
This patch adds initial support for the Cortex-A32 core.
It is an ARMv8-A core and this patch enables the -mcpu=cortex-a32 and
-mtune=cortex-a32 options.
The initial tunings are set to the same parameters as for Cortex-A35.
Bootstrapped and tested on arm-none-linux-gnueabihf together wi
On 24/02/16 10:49, Kyrill Tkachov wrote:
> Hi all,
>
> This patch adds initial support for the Cortex-A32 core.
> It is an ARMv8-A core and this patch enables the -mcpu=cortex-a32 and
> -mtune=cortex-a32 options.
>
> The initial tunings are set to the same parameters as for Cortex-A35.
>
> Boots
Hi all,
This is the GCC 5 backport of
https://gcc.gnu.org/ml/gcc-patches/2016-02/msg01338.html.
The differences are that TARGET_HAVE_LPAE has to be defined in arm.h in a
different way because
the ARM_FSET_HAS_CPU1 mechanism doesn't exist on this branch.
Also, the scan-assembler tests that check
Hi all,
This is the GCC 4.9 backport of
https://gcc.gnu.org/ml/gcc-patches/2016-02/msg01338.html.
The differences are that TARGET_HAVE_LPAE has to be defined in arm.h in a
different way because
the ARM_FSET_HAS_CPU1 mechanism doesn't exist on this branch. Also, due to the
location of insn_flag
On Tue, Feb 23, 2016 at 9:06 PM, Jakub Jelinek wrote:
> Hi!
>
> This function has changed last year to support embedded VECTOR_CSTs in the
> ctor elements. Before that change, there was no pos var and idx used to
> match exactly the indices in the new vector, but if there is any VECTOR_CST,
> it
On Wed, Feb 24, 2016 at 5:07 AM, Alexandre Oliva wrote:
> Hi, Richard,
>
> Thanks for the feedback. I'm afraid I can't quite figure out what
> you're getting at. Please see below.
>
> On Feb 22, 2016, Richard Biener wrote:
>
>> I think this breaks early-debug assumptions in creating new decl DI
On Wed, Feb 24, 2016 at 10:34 AM, Kyrill Tkachov
wrote:
> Hi all,
>
> In this PR we get an ICE when the hoist pass ends up creating an
> (insn 88 0 0 (set (reg:OI 136)
> (const_int 0 [0])) -1
> (nil))
>
> instruction. AArch64 doesn't support such an OImode set.
> The only OImode set o
On Feb 10, 2016, Alexandre Oliva wrote:
> On Jan 26, 2016, Alexandre Oliva wrote:
>> We don't want finish_function to be called recursively from mark_used.
>> However, it's desirable and necessary to call itself recursively when
>> performing delayed folding, because that may have to instantiate
On 17/02/16 16:48, Tom de Vries wrote:
On 17/02/16 13:30, Jakub Jelinek wrote:
On Wed, Feb 17, 2016 at 01:02:17PM +0100, Tom de Vries wrote:
Mark offload symbols as global in lto
I'm really not familiar with that part of LTO, so I'm CCing Honza and
Richard here.
2016-02-08 Tom de Vries
bug 69916 is an instance of an openacc loop that is lowered during omp-low, but
determined to be a nop and removed before oacc-device-lower. (j is dead after
the loop). This confused the openacc loop transform code, which still detected
it via its loop header, but encountered no IFN_GOACC_LOOP
Ping*2
Thanks,
Kyrill
On 17/02/16 10:12, Kyrill Tkachov wrote:
Ping.
https://gcc.gnu.org/ml/gcc-patches/2016-02/msg00634.html
As mentioned before, this is actually a fix for PR target/69538.
I got confused when writing the cover letter and ChangeLog...
Thanks,
Kyrill
On 09/02/16 17:24, Kyril
On 02/23/2016 11:24 AM, Patrick Palka wrote:
1. making tsubst_copy_and_build retain the REF_PARENTHESIZED_P flag when
processing an INDIRECT_REF, or by
This should happen in any case.
2. moving the call to maybe_undo_parenthesized_ref in finish_call_expr before
the assignment of orig_fn so th
OK.
Jason
After discussion with the ARM port maintainers we have decided that now
is probably the right time to deprecate support for versions of the ARM
Architecture prior to ARMv4t. This will allow us to clean up some of
the code base going forwards by being able to assume:
- Presence of half-word data ac
A trivial fix to .
Tested x86_64-linux, committed to trunk and gcc-5-branch.
commit 124d28afe0c515a5d60ba2bbe788c2029329dbc5
Author: Jonathan Wakely
Date: Wed Feb 24 13:15:53 2016 +
libstdc++/69939 Qualify get and forward
PR libstdc++/69939
* include/experimental/tuple
Ping.
https://gcc.gnu.org/ml/gcc-patches/2016-02/msg00396.html
Thanks,
Kyrill
On 05/02/16 10:00, Kyrill Tkachov wrote:
Hi all,
I've been auditing the patterns in the arm backend that were added/modified for
-mrestrict-it
and I've come up with a few runtime tests that end up generating those pa
On 02/23/2016 04:21 PM, Richard Biener wrote:
> On Wed, Nov 4, 2015 at 4:03 PM, Mikhail Maltsev wrote:
>> On 11/03/2015 02:35 AM, Jeff Law wrote:
>>> This is good fore the trunk too. Please install.
>>>
>>> Thanks!
>>>
>>> jeff
>>
>> Committed as r229758.
>
>> grep ENABLE_CHECKING *.[ch]
> dwarf
On Fri, Feb 5, 2016 at 10:00 AM, Kyrill Tkachov
wrote:
> Hi all,
>
> I've been auditing the patterns in the arm backend that were added/modified
> for -mrestrict-it
> and I've come up with a few runtime tests that end up generating those
> patterns.
> This patch contains 4 tests for 4 patterns tha
Hi,
On Wed, 24 Feb 2016, Martin Liška wrote:
> >> grep ENABLE_CHECKING *.[ch]
> > dwarf2out.c:#if ENABLE_CHECKING
> > dwarf2out.c:#if ENABLE_CHECKING
> > dwarf2out.c:#if ENABLE_CHECKING
> > dwarf2out.h:#if ENABLE_CHECKING
>
> Hi Richi.
>
> Removal in dwarf2out.c is not possible due to assignmen
On 24/02/16 10:12, Dominique d'Humières wrote:
The test gcc.dg/builtins-68.c fails on x86_64-apple-darwin15:
FAIL: gcc.dg/builtins-68.c (test for errors, line 79)
FAIL: gcc.dg/builtins-68.c (test for excess errors)
Excess errors:
/opt/gcc/work/gcc/testsuite/gcc.dg/builtins-68.c:107:40: warning
On 02/24/2016 03:12 AM, Dominique d'Humières wrote:
The test gcc.dg/builtins-68.c fails on x86_64-apple-darwin15:
Thanks for the heads up. I see it also fails on i686-pc-linux-gnu
and likely other 32-bit targets for similar reasons. Let me adjust
it today.
Martin
FAIL: gcc.dg/builtins-68.
On Wed, Feb 24, 2016 at 07:37:56AM -0700, Martin Sebor wrote:
> On 02/24/2016 03:12 AM, Dominique d'Humières wrote:
> >The test gcc.dg/builtins-68.c fails on x86_64-apple-darwin15:
>
> Thanks for the heads up. I see it also fails on i686-pc-linux-gnu
> and likely other 32-bit targets for similar
gcc.dg/debug/dwarf2/prod-options.c currently FAILs on Solaris when the
native assembler is used:
FAIL: gcc.dg/debug/dwarf2/prod-options.c scan-assembler DW_AT_producer: "GNU C
This happens because the DW_AT_producer line scanned for is formatted
slightly differently: on Solaris/x86 with as, I see
The following fixes bogus SCEV analysis for expressions that are only
executed conditionally [note: conditionally here doesn't include
after a taken exit]. Basically we have to make sure further analysis
does not attempt to use undefined overflow for expressions we don't
know whether they are com
On 02/24/2016 07:46 AM, Jakub Jelinek wrote:
On Wed, Feb 24, 2016 at 07:37:56AM -0700, Martin Sebor wrote:
On 02/24/2016 03:12 AM, Dominique d'Humières wrote:
The test gcc.dg/builtins-68.c fails on x86_64-apple-darwin15:
Thanks for the heads up. I see it also fails on i686-pc-linux-gnu
and l
On 02/24/2016 03:27 PM, Michael Matz wrote:
> But nothing can set ENABLE_CHECKING anymore (the macro is meanwhile called
> CHECKING_P), so all that code is dead anyway. So either the new macro
> should be used or that code should be removed.
>
>
> Ciao,
> Michael.
Good point, well the change
This patch from Xia Bin fixes libgo to lock a goroutine to a thread
during a cgo call. That is how the master library works, and it
avoids confusion if the C code calls back into the Go code.
Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu. Committed
to mainline.
Ian
Index: gcc/go/gofro
Various projects have been having trouble with the new -flifetime-dse
clobber at the beginning of the constructor, so this patch allows them
to pass -flifetime-dse=1 to disable that clobber while still keeping the
one at the end of the destructor.
Tested x86_64-pc-linux-gnu, applying to trunk.
While talking about constexpr issues it occurred to me that we ought not
fold away calls to constexpr functions in regular expressions when the
user has specified -fno-inline, so that they can debug those calls normally.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit bf89c79569525294101e
On Wed, Feb 24, 2016 at 10:15:35AM -0500, Jason Merrill wrote:
> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi
> @@ -6809,7 +6809,10 @@ value, and any changes during the lifetime of the
> object are dead when
> the object is destroyed. Normally dead store elimination will take
> advanta
On 02/24/2016 03:53 PM, Martin Liška wrote:
On 02/24/2016 03:27 PM, Michael Matz wrote:
But nothing can set ENABLE_CHECKING anymore (the macro is meanwhile called
CHECKING_P), so all that code is dead anyway. So either the new macro
should be used or that code should be removed.
Good point, w
Hi!
On Tue, 23 Feb 2016 08:37:07 +0100, Tom de Vries wrote:
> On 22/02/16 19:07, Ilya Verbin wrote:
> > 2016-02-22 18:13 GMT+03:00 Thomas Schwinge:
> >> >On Sat, 20 Feb 2016 13:54:20 +0300, Ilya Verbin wrote:
> >>> >>On Fri, Feb 19, 2016 at 15:53:08 +0100, Jakub Jelinek wrote:
> >> >On Wed,
On Tue, Feb 23, 2016 at 06:45:08AM -0800, H.J. Lu wrote:
> On Fri, Feb 19, 2016 at 8:21 AM, Martin Jambor wrote:
> > Hi,
> >
> > in PR 69666, SRA attempts to turn a load from an aggregate that is
> > uninitialized into a load from a default definition SSA name (which
> > something it does to gener
On Wed, Feb 24, 2016 at 17:13:35 +0100, Thomas Schwinge wrote:
> On Tue, 23 Feb 2016 08:37:07 +0100, Tom de Vries
> wrote:
> > On 22/02/16 19:07, Ilya Verbin wrote:
> > > 2016-02-22 18:13 GMT+03:00 Thomas Schwinge:
> > >> >On Sat, 20 Feb 2016 13:54:20 +0300, Ilya Verbin
> > >> >wrote:
> > >>> >
The following is another issue with macros from system headers. In this case
bool is defined in a system header to expand to _Bool and the "is promoted to"
warning didn't trigger because of that. The fix is to use the expanded
location.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
201
This is a minor issue in the C FE, where it on an invalid code generated bogus
FUNCTION_DECL with ARRAY_TYPE as a type -- and gimplifier can't digest that.
I think the code in finish_decl, whereby we update the type of shadowed global
variables should not overwrite a type of totally unrelated decl
On 02/24/2016 07:52 AM, Martin Sebor wrote:
On 02/24/2016 07:46 AM, Jakub Jelinek wrote:
On Wed, Feb 24, 2016 at 07:37:56AM -0700, Martin Sebor wrote:
On 02/24/2016 03:12 AM, Dominique d'Humières wrote:
The test gcc.dg/builtins-68.c fails on x86_64-apple-darwin15:
Thanks for the heads up. I
On Wed, 24 Feb 2016, Richard Earnshaw (lists) wrote:
> After discussion with the ARM port maintainers we have decided that now
> is probably the right time to deprecate support for versions of the ARM
> Architecture prior to ARMv4t. This will allow us to clean up some of
Should this include -mar
On Wed, 24 Feb 2016, Marek Polacek wrote:
> This is a minor issue in the C FE, where it on an invalid code generated bogus
> FUNCTION_DECL with ARRAY_TYPE as a type -- and gimplifier can't digest that.
>
> I think the code in finish_decl, whereby we update the type of shadowed global
> variables
This adds a new function to libsupc++ which will free the memory still
in use by the pool used for allocating exceptions when malloc fails.
This is similar to glibc's __libc_freeres, which valgrind (and other
tools?) use to tell glibc to deallocate everything before exiting.
I initially called i
Here is a new patch for PR 68273. The original problem with gsoap has
been fixed by changing GCC to not create overly-aligned variables in
the SRA pass but the MIPS specific problem of how user-aligned variables
are passed to functions remains.
Because MIPS GCC is internally inconsistent, it seem
Hi!
This patch adds TREE_NO_WARNING to two places that didn't have it before
and avoids folding those conditions at those spots (partly to match
C++ delayed folding intent, partly to avoid duplicating TREE_NO_WARNING
propagation).
The more controversial stuff is that we need to preserve TREE_NO_W
Hi!
This is something that I hope early debug for LTO will eventually
fix, but we aren't there yet and current trunk emits bogus debug info
for inlines - DW_TAG_subprogram of the inline doesn't contain any
parameters/variables/lexical blocks etc. in it, but in
DW_TAG_inlined_subroutine we add all
On Mon, Feb 22, 2016 at 16:13:07 +0100, Thomas Schwinge wrote:
> (..., and similar for others.) The if-exists spec function only works
> for absolute paths (I have not researched, why?), so it won't locate the
> files for relative -Bbuild-gcc/[...] prefixes, and linking will fail:
>
> /tmp/cc
On Wed, Feb 24, 2016 at 10:29:47PM +0300, Ilya Verbin wrote:
> Done.
> Here is a follow up patch. OK for trunk? Bootstrapped and regtested.
Ok with appropriate ChangeLog entry.
Jakub
Hello,
the above bug appears to have been fixed over 2.5 years ago.
It does not trigger with 4.9, 5 and 6 trunk, but does with 4.8.0 and
before.
I recommend to close the bug, while adding a testcase to the trunk's
testsuite. See e.g. the attached example.
Harald
2016-02-24 Harald Anlauf
On Wed, 24 Feb 2016, Jason Merrill wrote:
On 02/23/2016 11:24 AM, Patrick Palka wrote:
1. making tsubst_copy_and_build retain the REF_PARENTHESIZED_P flag when
processing an INDIRECT_REF, or by
This should happen in any case.
2. moving the call to maybe_undo_parenthesized_ref in finish_call_
The testcase in the BZ is invalid, but there's a valid variant that also
ICEd. I've fixed the compiler to do the right thing with three
different variants.
Tested x86_64-pc-linux-gnu, applying to trunk. Changes for the valid
variant also applied to 5.
commit e99dbeae7942d066e234b3e31ec73e24d
On 02/24/2016 02:05 PM, Jakub Jelinek wrote:
+ && integer_zerop (tree_strip_nop_conversions (TREE_OPERAND (org_x,
+ 1
Why check this? I think we want this handling for all TREE_NO_WARNING
comparisons.
Jason
On Wed, Feb 24, 2016 at 02:57:49PM -0500, Jason Merrill wrote:
> On 02/24/2016 02:05 PM, Jakub Jelinek wrote:
> >+ && integer_zerop (tree_strip_nop_conversions (TREE_OPERAND (org_x,
> >+ 1
>
> Why check this? I think we wan
Jakub,
this patch fixes the ICE reported in pr69916
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69916) The loop is lowered at
omp-lowering, but subsequently determined to be dead before we get to
oacc-target-lower. The loop CF is removed along with the (pure) IFN_OACC_LOOP
function calls
On 02/24/16 20:42, Harald Anlauf wrote:
> Hello,
>
> the above bug appears to have been fixed over 2.5 years ago.
> It does not trigger with 4.9, 5 and 6 trunk, but does with 4.8.0 and
> before.
>
> I recommend to close the bug, while adding a testcase to the trunk's
> testsuite. See e.g. the at
OK.
Jason
On 02/24/2016 03:05 PM, Jakub Jelinek wrote:
On Wed, Feb 24, 2016 at 02:57:49PM -0500, Jason Merrill wrote:
On 02/24/2016 02:05 PM, Jakub Jelinek wrote:
+ && integer_zerop (tree_strip_nop_conversions (TREE_OPERAND (org_x,
+
On 02/24/2016 10:25 AM, Jakub Jelinek wrote:
That should be @option{-flifetime-dse=1} I think. Shouldn't -flifetime-dse=
be also in @opindex at the beginning of the paragraph, and documented what
the values mean (0 equivalent of -fno-lifetime-dse (or document it vice
versa) and 2 full lifetime d
OK.
Jason
Steve Ellcey writes:
> Here is a new patch for PR 68273. The original problem with gsoap has
> been fixed by changing GCC to not create overly-aligned variables in
> the SRA pass but the MIPS specific problem of how user-aligned variables
> are passed to functions remains.
>
> Because MIPS GCC
The previous gcov behavior was to always output errors on the stderr channel.
This is fine for most uses, but some programs will require stderr to be
untouched by libgcov for certain tests. This change allows configuring
the gcov output via an environment variable which will be used to open
the app
On Wed, 24 Feb 2016, Steve Ellcey wrote:
> I also added a way to turn that warning off in case the user doesn't
> want to see it (-mno-warn-aligned-args). I did not add an option
Any command-line options need documenting in invoke.texi.
--
Joseph S. Myers
jos...@codesourcery.com
On 02/23/2016 04:56 AM, Richard Biener wrote:
On Mon, Feb 22, 2016 at 4:34 PM, Jeff Law wrote:
On 02/22/2016 07:34 AM, Richard Biener wrote:
Hum, but then you get to "inifinite" compiles again when LRA is buggy
or the user presents it with an impossible to handle asm.
Neither should be happ
Hi!
Sorry for the late answer...
On Sat, 19 Sep 2015 14:00:23 +0200, Samuel Thibault
wrote:
> On Linux, -p and -pg do not make gcc link against libc_p.a, only
> -profile does (as documented in r11246), and thus people expect -p
(Yo, 20 years ago...)
> and -pg to work without libc_p.a installe
Some DImode rotate-right-and-mask can be implemented best with a rlwinm
instruction: those that could be a lshiftrt instead of a rotatert, while
the mask is not right-aligned. Why the rotate in the testcase is not
optimised to a plain shift is another question, but we need to handle
it here anyway
This patch adds support for builtin overflow of add, subtract and
negate. This patch is targeted for gcc 7 stage 1. It was tested with no
regressions in arm and thumb modes on the following targets:
arm-non-linux-gnueabi
arm-non-linux-gnuabihf
armeb-none-linux-gnuabihf
arm-non-eabi
2016-02-24
On Wed, 2016-02-24 at 13:46 -0800, Matthew Fortune wrote:
> Thanks for enumerating all the cases. I'd not looked at all of them. I
> do agree that we need a fix given the existing inconsistencies.
>
> One question I have is where does an over aligned argument get pushed
> to the stack with the pa
Thomas Schwinge, on Wed 24 Feb 2016 23:46:36 +0100, wrote:
> I guess getting -D_REENTRANT for -pthread won't do us any harm?
It won't.
> > --- gcc/config/i386/gnu.h.orig 2015-09-17 21:41:13.0 +
> > +++ gcc/config/i386/gnu.h 2015-09-17 23:03:57.0 +
> > @@ -27,11 +27,
This patch from Steve on c.l.f
Fixes the segfault from attempting a string compare where there is no string
yet.
Regression tested on x86-64. New test case.
OK for trunk.
Regards,
Jerry
2016-02-24 Jerry DeLisle
Steven G. Kargl
PR fortran/69110
* io.c (gfc_m
PR69740 shows two instances where one or more transformations ultimately
lead to the removal of a basic block.
In both cases, removal of the basic block removes a path into an
irreducible region and turns the irreducible region into a natural loop.
When that occurs we need to be requesting
On 02/22/2016 02:26 PM, Jakub Jelinek wrote:
Hi!
The following testcase is miscompiled, because prepare_shrink_wrap
attempts to copyprop_hardreg_forward_1 the first bb. We see
DImode rbx being copied to DImode r11, and then we have (dead since
postreload) an assignment of SImode r11d to SImode
On 02/22/2016 02:22 AM, Bin.Cheng wrote:
My only question is why didn't you use FOR_EACH_SUBRTX_VRA from rtl-iter.h
to walk the RTX expressions in collect_address_parts and
canonicalize_address_mult?
Hi Jeff,
Nothing special, just I haven't used this before, also
canonicalize_address_mult is al
Hi Jerry and Steve,
OK for trunk.
OK.
Regards
Thomas
79 matches
Mail list logo
