Georg-Johann Lay writes:
> On 28.10.2016 17:58, Mike Stump wrote:
>> On Oct 27, 2016, at 3:16 AM, Georg-Johann Lay wrote:
>>>
>>> Now imagine some arithmetic like &&LAB2 - &&LAB1. This might result in
>>> one or two stub addresses, and difference between such addresses is a
>>> complete differe
Unfortunately, I committed an earlier version of the patch that was buggy. I
have updated the trunk to include the proper version of the file rs6000.h that
does bootstrap. Sorry about htat.
--
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@l
On Nov 3, 2016, at 8:25 AM, Georg-Johann Lay wrote:
>
> On 28.10.2016 17:58, Mike Stump wrote:
>> On Oct 27, 2016, at 3:16 AM, Georg-Johann Lay wrote:
>>>
>>> Now imagine some arithmetic like &&LAB2 - &&LAB1. This might result in
>>> one or two stub addresses, and difference between such addre
On Sat, Oct 29, 2016 at 08:30:46PM -0700, Jerry DeLisle wrote:
>
> OK for trunk?
>
> 2016-10-29 Jerry DeLisle
>
> PR fortran/54679
> * io.c (check_format): Adjust checks for FMT_L to treat a zero
> width as an extension, giving warnings or error as appropriate.
> Impro
On Thu, Nov 03, 2016 at 02:16:48PM +0100, Andre Vehreschild wrote:
>
> Bootstraps and regtests fine on x86_64-linux/F23. Ok for trunk?
>
> @Dominique: Would you give it a go on your open patch collection? Maybe it
> fixes one PR, but I am not very hopeful, because the patch is merely removing
> c
* Claudiu Zissulescu [2016-11-01 16:28:34
+0100]:
> This is an updated version of the patch that can be applied as is.
>
> Ok to apply?
> Claudiu
>
> gcc/
> 2016-05-09 Claudiu Zissulescu
>
> * config/arc/arc.c (arc_process_double_reg_moves): Change.
> * config/arc/arc.md (movsi
On Thu, Nov 03, 2016 at 06:22:11PM -0400, Michael Meissner wrote:
> Aaron has been running tests on the simulator, and some of the tests fails on
> little endian systems. The failing tests do int extracts from a V4SImode
> vector. In looking at the code, the vector index was adjusted when the low
* Claudiu Zissulescu [2016-10-31 16:46:17
+0100]:
> Please find the updated patch.
>
> What is new:
> - The .def files are having a comment block on how to add new lines.
> - The arc_seen_option is not used.
> - The arc_cpu* variables are not used.
>
> Please let me know if I miss something,
Aaron has been running tests on the simulator, and some of the tests fails on
little endian systems. The failing tests do int extracts from a V4SImode
vector. In looking at the code, the vector index was adjusted when the low
level extract instruction was created, and then adjusted again within t
Hi,
I thought in preparation of the new C++ warning about wrong
declarations of builtin functions it would be good to fix some of the
more obvious bugs in the testsuite first.
Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?
Thanks
Bernd.
2016-11-03 Bernd Edlinger
P
On Nov 3, 2016, at 1:01 PM, Ximin Luo wrote:
> Log snippets attached.
Ick. You missed the utility of contrib/compare_tests. :-)
If you say:
contrib/compare_tests oldbuilddir newbuilddir
You can then sit back and see everything as you'd expect and want. The output
is priority sorted and u
On Thu, Nov 03, 2016 at 04:05:59PM -0400, Michael Meissner wrote:
> --- gcc/config/rs6000/rs6000.md (revision 241715)
> +++ gcc/config/rs6000/rs6000.md (working copy)
> @@ -376,7 +376,7 @@
>(TF "TARGET_HARD_FLOAT
> && (TARGET_FPRS || TARGET_E500_DOUBLE)
> && TARGET_LONG_DOUB
Hi,
WORD_REGISTER_OPERATIONS and LOAD_EXTEND_OP are partially used directly as
preprocessor macros and partially tested in the code. This patch brings a bit
of consistency into this by converting the remaining macro cases.
Tested on SPARC/Solaris and x86-64/Linux, OK for the mainline?
2016-1
Hi
I might not be the right one to propose this patch as I am not sure
that I fully understand gnu-versioned-namespace.ver organization. But
with it following test failures when using versioned namespace vanish:
FAIL: 20_util/allocator/overaligned.cc (test for excess errors)
FAIL: ext/bit
This patch fixes PR target/77993, which is a bug preventing bootstrapping on
32-bit PowerPC Linux targets.
The issue is that some of the insns that support IFmode (IBM extended double
mode when long double is IEEE 128-bit floating point in the future) did not
check for -msoft-float, and disable IF
Ximin Luo:
> Testing
> ===
>
> I've tested these patches on a Debian testing/unstable x86_64-linux-gnu
> system.
> So far I've only run the new tests that this patch adds, on a
> disable-bootstrap
> build. I will do a full bootstrap and run the full testsuite over the next few
> days, both w
On Wed, Nov 2, 2016 at 5:15 PM, Bernd Edlinger
wrote:
> On 11/02/16 18:51, Jason Merrill wrote:
>> On 11/02/2016 02:11 AM, Bernd Edlinger wrote:
>>> On 11/01/16 19:15, Bernd Edlinger wrote:
On 11/01/16 18:11, Jason Merrill wrote:
> On Tue, Nov 1, 2016 at 11:45 AM, Bernd Edlinger
> wr
On Thu, 3 Nov 2016, Richard Biener wrote:
The transform would also work for vectors (element_precision for
the test but also a value-matching zero which should ensure the
same number of elements).
Um sorry, I didn't get how to check vectors to be of equal length by a
matching zero.
Could you pl
On Thu, Nov 3, 2016 at 12:38 PM, Jakub Jelinek wrote:
> On Wed, Nov 02, 2016 at 01:19:09PM -0400, Jason Merrill wrote:
>> On Wed, Nov 2, 2016 at 12:33 PM, Jakub Jelinek wrote:
>> > On Wed, Nov 02, 2016 at 04:44:05PM +0100, Jakub Jelinek wrote:
>> >> which means if gen_type_die or gen_type_die_wit
On 11/03/16 07:11, Rainer Orth wrote:
Ok for mainline now, and for backports to the gcc-6 and gcc-5 branches
after some soak time?
Yes, please. Thanks.
On Thu, 2016-11-03 at 17:43 +0100, Bernd Schmidt wrote:
> On 11/03/2016 05:35 PM, Martin Jambor wrote:
> >
> > * print-rtl.c (print_rtx_operand_codes_E_and_V): Print how many
> > times
> > an element is repeated istead of printing each repeated
> > element.
>
> "instead"
>
> > ---
> > g
On November 3, 2016 6:11:07 PM GMT+01:00, Marc Glisse
wrote:
>On Thu, 3 Nov 2016, Prathamesh Kulkarni wrote:
>
>> On 3 November 2016 at 16:13, Richard Biener
>wrote:
>>> On Thu, 3 Nov 2016, Prathamesh Kulkarni wrote:
>>>
Hi Richard,
The attached patch tries to fix PR35691, by adding th
On Thu, 3 Nov 2016, Richard Biener wrote:
On Thu, 3 Nov 2016, Prathamesh Kulkarni wrote:
Hi Richard,
The attached patch tries to fix PR35691, by adding the following two
transforms to match.pd:
(x == 0 && y == 0) -> (x | typeof(x)(y)) == 0.
(x != 0 || y != 0) -> (x | typeof(x)(y)) != 0.
For G
On 3 November 2016 at 23:08, Andrew Pinski wrote:
> This patch no longer applies after the recent changes (starting around
> a month ago) to aarch64-cores.def. Please updat the patch for the
> recent changes
Sorry about that, I'll post an updated patch shortly.
Siddhesh
Over the years, GCC has had various ways of setting the default CPU. As
things have changed, the ARM back-end hasn't necessarily kept up with
some of the changes and this has resulted in some convoluted logic in
places. This patch cleans up some of this and eliminates entirely the
need for SUBTAR
This patch has proven to be effective at warning users when the compiler
falls back to host execution due to insufficient parallelism (at least
from parloop's perspective) inside kernels regions. At the moment, acc
kernels are restricted to gang-level parallelism. Consequently, if
parloops fails to
On 03/11/16 13:01, Bernd Schmidt wrote:
Index: gcc/emit-rtl.c
===
--- gcc/emit-rtl.c (revision 241233)
+++ gcc/emit-rtl.c (working copy)
@@ -6169,17 +6169,18 @@ emit_copy_of_insn_after (rtx_insn *insn,
which may be
Adds Rust symbol demangler. Rust mangles symbols using GNU_V3 style,
adding a hash and various special character subtitutions. This adds
a new rust style to cplus_demangle and adds 3 helper functions
rust_demangle, rust_demangle_sym and rust_is_mangled.
rust-demangle.c was written by David. Mark d
Hi,
On Fri, Oct 28, 2016 at 02:03:47PM +1100, kugan wrote:
>
> ...snip...
>
> I have also separated the constant parameter conversion out and posted as
> https://gcc.gnu.org/ml/gcc-patches/2016-10/msg02309.html. This is now
> handling just unary pass-through jump functions.
>
> Bootstrapped and
Hello all,
On 11/02/2016 05:33 PM, Jakub Jelinek wrote:
On Wed, Nov 02, 2016 at 04:44:05PM +0100, Jakub Jelinek wrote:
You could find an Ada test that uses the code and verify that the
output stays the same?
I can try to find the patch that introduced it and if it contained any
testcases.
I
https://gcc.gnu.org/ml/fortran/2016-10/msg00222.html
On Wed, Oct 26, 2016 at 10:14 AM, Fritz Reese wrote:
> All,
>
> Attached is a patch to the GNU Fortran front-end and runtime library
> (libgfortran) which accepts real numbers with missing exponents as if
> '0' was given as the exponent when the
On Thu, 3 Nov 2016, Prathamesh Kulkarni wrote:
On 3 November 2016 at 16:13, Richard Biener wrote:
On Thu, 3 Nov 2016, Prathamesh Kulkarni wrote:
Hi Richard,
The attached patch tries to fix PR35691, by adding the following two
transforms to match.pd:
(x == 0 && y == 0) -> (x | typeof(x)(y)) =
On Nov 3, 2016, at 2:29 AM, Senthil Kumar Selvaraj
wrote:
>
> The below patch adds a new effective target keyword (store_merge) for
> use in the store_merging_xxx.c tests.
>
> The tests currently require non_strict_align, but they still fail for the
> avr.
> Eyeballing the dump, I found th
Hi,
When using a callee-saved register to save the frame pointer the Thumb-1
prologue fails to save the callee-saved register before that. For ARM and
Thumb-2 targets the frame pointer is handled as a special case but nothing is
done for Thumb-1 targets. This patch adds the same logic for Thum
Hi!
My recent optimize_abbrev_table optimization apparently broke Solaris
bootstrap.
The bug is specific I think just to -gdwarf-{2,3} -gno-strict-dwarf, where
DW_FORM_exprloc can't be used for location expressions and some location
expression contains DW_OP_GNU_{{const,regval,deref}_type,convert,
On 11/03/2016 05:35 PM, Martin Jambor wrote:
* print-rtl.c (print_rtx_operand_codes_E_and_V): Print how many times
an element is repeated istead of printing each repeated element.
"instead"
---
gcc/print-rtl.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletio
On Wed, Nov 02, 2016 at 01:19:09PM -0400, Jason Merrill wrote:
> On Wed, Nov 2, 2016 at 12:33 PM, Jakub Jelinek wrote:
> > On Wed, Nov 02, 2016 at 04:44:05PM +0100, Jakub Jelinek wrote:
> >> which means if gen_type_die or gen_type_die_with_usage doesn't
> >> use the langhook, then we'd emit a comp
Hi,
this patch comes from our GCN BE branch. Because vectors of that
architectures have many elements, RTL dumps can get quite unwieldy when
all elements are printed out all the time. However, pretty much all the
time it is the same value repeated over and over again, which lead us to
the follow
Hi,
On Fri, Oct 28, 2016 at 01:58:13PM +1100, kugan wrote:
> > Do I understand it correctly that extract_range_from_unary_expr deals
> > with any potential type conversions better (compared to what you did
> > before here)?
>
> Yes, this can be wrong at times too as reported in
> https://gcc.gnu.
OpenACC permits the user to request more gang, worker and vector level
parallelism than what the compiler can utilize. For instance, if the
user writes worker routine without including a worker-partitioned loop,
the compiler will not generate worker-partitioned code for that function.
The intent b
On Thu, Nov 3, 2016 at 3:03 AM, Siddhesh Poyarekar
wrote:
> This adds an mcpu option for the upcoming Qualcomm Falkor core. This
> is identical to the qdf24xx part that was added earlier and hence
> retains the same tuning structure and continues to have the a57
> pipeline for now. The part numb
The vec_interleave_{low, high} standard patterns were removed 5 years ago.
Tested on SPARC/Solaris, applied on the mainline.
2016-11-03 Eric Botcazou
* config/sparc/sparc.md (vec_interleave_lowv8qi): Delete.
(vec_interleave_highv8qi): Likewise.
--
Eric BotcazouIndex: config
I managed to forget to mask the thing inserted. Tested on powerpc64-linux
{-m32,-m64}, and Bin tested on arm. Applying to trunk.
Segher
2016-11-03 Segher Boessenkool
PR rtl-optimization/78186
* combine.c (change_zero_ext): Mask the RHS of a zero_extract as
well, wh
On Thu, Nov 3, 2016 at 1:35 PM, Evgeny Kudryashov wrote:
> Hello,
>
> I'm facing the following problem related to ivopts. The problem is that GCC
> generates a lot of induction variables and as a result there is an
> unnecessary increase of stack usage and register pressure.
>
> For instance, for
On Thu, Nov 03, 2016 at 04:29:05PM +0100, Eric Botcazou wrote:
> > Is VRP the right pass to do this optimisation or should a later
> > pass rather attempt to eliminate the new use of b_5 instead? Uli
> > has brought up the idea a mini "sign extend elimination" pass that
> > checks if the result of
On Thu, Nov 03, 2016 at 09:29:07AM +0100, Richard Biener wrote:
> On Wed, Nov 2, 2016 at 4:27 PM, Segher Boessenkool
> wrote:
> > On Wed, Nov 02, 2016 at 02:51:41PM +0100, Richard Biener wrote:
> >> >> I don't believe it needs a cleanup on every iteration. One cleanup at
> >> >> the end should wor
> Is VRP the right pass to do this optimisation or should a later
> pass rather attempt to eliminate the new use of b_5 instead? Uli
> has brought up the idea a mini "sign extend elimination" pass that
> checks if the result of a sign extend could be replaced by the
> original quantity in all plac
[Please cc me and Segher on PowerPC / AIX patches.]
I bootstrapped successfully with the patch and ran the testsuite.
Without patch:
https://gcc.gnu.org/ml/gcc-testresults/2016-11/msg00186.html
With patch:
https://gcc.gnu.org/ml/gcc-testresults/2016-11/msg00233.html
Not exactly the same revisio
On 28.10.2016 17:58, Mike Stump wrote:
On Oct 27, 2016, at 3:16 AM, Georg-Johann Lay wrote:
Now imagine some arithmetic like &&LAB2 - &&LAB1. This might result in
one or two stub addresses, and difference between such addresses is a
complete different thing than the difference between the ori
>
> 2016-10-31 Martin Liska
>
> * libgcov-profiler.c (__gcov_time_profiler): Remove.
> (__gcov_time_profiler_atomic): Likewise.
>
> gcc/ChangeLog:
>
> 2016-10-31 Martin Liska
>
> * profile.c (instrument_values): Fix coding style.
> (branch_prob): Use renamed funct
On Thu, Nov 03, 2016 at 04:03:22PM +0100, Dominik Vogt wrote:
> I've been trying to fix some bad tree-ssa related optimisation for
> s390x and come up with the attached experimental patch. The patch
> is not really good - it breaks some situations in which the
> optimisation was useful. With this
I've been trying to fix some bad tree-ssa related optimisation for
s390x and come up with the attached experimental patch. The patch
is not really good - it breaks some situations in which the
optimisation was useful. With this code:
void bar(long);
void foo (char a)
{
long l;
char
Hello.
As Honza noticed we spent quite some time in __gcov_time_profiler:
perf report for Postgres make check command:
4.10% postgres postgres[.]__gcov_time_profiler
Thus I rewrote the profiling code directly to GIMPLE statements:
_4 = __gcov7.main[0];
if (_4 == 0)
goto ;
else
On 3 November 2016 at 16:13, Richard Biener wrote:
> On Thu, 3 Nov 2016, Prathamesh Kulkarni wrote:
>
>> Hi Richard,
>> The attached patch tries to fix PR35691, by adding the following two
>> transforms to match.pd:
>> (x == 0 && y == 0) -> (x | typeof(x)(y)) == 0.
>> (x != 0 || y != 0) -> (x | ty
Ping this patch again.
On 2016/9/21 12:43 AM, Cesar Philippidis wrote:
>> +/* Returns the number of mappings associated with the pointer or pset. PSET
>> > + have three mappings, whereas pointer have two. */
>> > +
>> > static int
>> > -find_pset (int pos, size_t mapnum, unsigned short *kinds
On 11/03/2016 03:03 PM, Jakub Jelinek wrote:
> On Thu, Nov 03, 2016 at 03:02:21PM +0100, Martin Liška wrote:
>>> But how would you be able to find out if there isn't any return *ptr; after
>>> the scope or similar (as MEM_REF)? With is_gimple_reg, they will be turned
>>> into SSA form and you can
As I've noticed some time ago, recent versions of Solaris
include this little gem:
#if __cplusplus >= 201103L
#undef _GLIBCXX_USE_C99_MATH
#undef _GLIBCXX_USE_C99_MATH_TR1
#endif
This renders a couple of perfectly good libstdc++ tests as UNSUPPORTED
and is completely unsustainable. Agreement
Hi,
According to analysis given by
https://gcc.gnu.org/ml/gcc/2016-10/msg00228.html, calls to
pedantic_non_lvalue_loc and code handling lvalue in
fold_cond_expr_with_comparison are useless now. Given this is complicated
legacy code, it may be better to change code step by step, rather than doi
On 3 November 2016 at 18:36, Uros Bizjak wrote:
> On Thu, Nov 3, 2016 at 1:58 PM, Eric Botcazou wrote:
>>> libfunc, as in "__{,u}divmod{di,ti}4 library function" is already
>>> implemented in libgcc. But the enablement of this function inside the
>>> compiler has to be performed by each target.
>
> FWIW here's a more complete version of my patch which I'm currently
> testing. Let me know if you think it's at least a good enough
> intermediate step to be installed.
It is, thanks.
> I think, the sel-sched example notwithstanding, this is something that
> normally should not be needed outsid
On 2016.11.03 at 14:57 +0100, Jakub Jelinek wrote:
> On Thu, Nov 03, 2016 at 02:55:03PM +0100, Markus Trippelsdorf wrote:
> > On 2016.11.03 at 14:47 +0100, Jakub Jelinek wrote:
> > > On Thu, Nov 03, 2016 at 02:35:57PM +0100, Markus Trippelsdorf wrote:
> > > > I don't have gathered detailed statisti
On Thu, Nov 03, 2016 at 03:02:21PM +0100, Martin Liška wrote:
> > But how would you be able to find out if there isn't any return *ptr; after
> > the scope or similar (as MEM_REF)? With is_gimple_reg, they will be turned
> > into SSA form and you can easily verify (uses of ASAN_POISON are a proble
> I guess it can be done. Currently the expander goes:
>
> --cut here--
> /* Check if optab_handler exists for divmod_optab for given mode. */
> if (optab_handler (tab, mode) != CODE_FOR_nothing)
> {
> quotient = gen_reg_rtx (mode);
> remainder = gen_reg_rtx (mode);
> ex
On 11/03/2016 02:44 PM, Jakub Jelinek wrote:
> Hi!
>
> FYI, I think it is much more important to get the initial patch in, so
> resolve the switch + declarations inside of its body stuff, add testcases
> for that and post for re-review and check in.
> These optimizations can be done even in stage3
On Thu, Nov 03, 2016 at 02:55:03PM +0100, Markus Trippelsdorf wrote:
> On 2016.11.03 at 14:47 +0100, Jakub Jelinek wrote:
> > On Thu, Nov 03, 2016 at 02:35:57PM +0100, Markus Trippelsdorf wrote:
> > > I don't have gathered detailed statistics. But for example a simple
> > > /* drop through */ in a
On 2016.11.03 at 14:47 +0100, Jakub Jelinek wrote:
> On Thu, Nov 03, 2016 at 02:35:57PM +0100, Markus Trippelsdorf wrote:
> > I don't have gathered detailed statistics. But for example a simple
> > /* drop through */ in a package header file will of course cause many
> > bogus warnings during the b
On Thu, Nov 03, 2016 at 02:48:33PM +0100, Bernd Schmidt wrote:
>
> On 11/03/2016 02:47 PM, Jakub Jelinek wrote:
> >On Thu, Nov 03, 2016 at 02:35:57PM +0100, Markus Trippelsdorf wrote:
> >>I don't have gathered detailed statistics. But for example a simple
> >>/* drop through */ in a package header
On 11/03/2016 02:47 PM, Jakub Jelinek wrote:
On Thu, Nov 03, 2016 at 02:35:57PM +0100, Markus Trippelsdorf wrote:
I don't have gathered detailed statistics. But for example a simple
/* drop through */ in a package header file will of course cause many
bogus warnings during the build on level 2.
On Thu, Nov 03, 2016 at 02:35:57PM +0100, Markus Trippelsdorf wrote:
> I don't have gathered detailed statistics. But for example a simple
> /* drop through */ in a package header file will of course cause many
> bogus warnings during the build on level 2.
> For the Linux kernel false positives dec
Hi,
The patch looks correct, however I would suggest to rewrite this bit of the code
urgently in separate patch as it is way too complex to assert it is now bug
free -
there are too many possible failure scenarios to list... Also it generates quite
inefficient code - pushable_regs should include
Hi!
FYI, I think it is much more important to get the initial patch in, so
resolve the switch + declarations inside of its body stuff, add testcases
for that and post for re-review and check in.
These optimizations can be done even in stage3.
On Thu, Nov 03, 2016 at 02:34:47PM +0100, Martin Liška
On 2016.11.03 at 14:24 +0100, Jakub Jelinek wrote:
> On Thu, Nov 03, 2016 at 01:55:33PM +0100, Markus Trippelsdorf wrote:
> > On 2016.11.03 at 13:32 +0100, Jakub Jelinek wrote:
> > > On Thu, Nov 03, 2016 at 01:22:11PM +0100, Bernd Schmidt wrote:
> > > > On 11/03/2016 12:58 PM, Jakub Jelinek wrote:
On Thu, Nov 03, 2016 at 09:27:55AM -0400, Jason Merrill wrote:
> On Thu, Nov 3, 2016 at 7:24 AM, Marek Polacek wrote:
> > On Tue, Nov 01, 2016 at 02:53:58PM +0100, Jakub Jelinek wrote:
> >> On Tue, Nov 01, 2016 at 09:41:20AM -0400, Jason Merrill wrote:
> >> > On Tue, Oct 25, 2016 at 9:59 AM, Marek
Hello,
I'm facing the following problem related to ivopts. The problem is that
GCC generates a lot of induction variables and as a result there is an
unnecessary increase of stack usage and register pressure.
For instance, for the attached testcase (tc_ivopts.c) GCC generates 26
induction va
On 11/02/2016 03:51 PM, Jakub Jelinek wrote:
> On Wed, Nov 02, 2016 at 03:38:25PM +0100, Martin Liška wrote:
>> it converts:
>> foo ()
>> {
>> char a;
>> char * p;
>> char _1;
>> int _2;
>> int _8;
>> int _9;
>>
>> :
>> ASAN_MARK (2, &a, 1);
>> a = 0;
>> p_6 = &a;
>> ASAN_MARK
On Thu, Nov 3, 2016 at 7:24 AM, Marek Polacek wrote:
> On Tue, Nov 01, 2016 at 02:53:58PM +0100, Jakub Jelinek wrote:
>> On Tue, Nov 01, 2016 at 09:41:20AM -0400, Jason Merrill wrote:
>> > On Tue, Oct 25, 2016 at 9:59 AM, Marek Polacek wrote:
>> > > On Mon, Oct 24, 2016 at 04:10:21PM +0200, Marek
On Tue, Oct 18, 2016 at 4:26 PM, Paolo Carlini wrote:
> Thus, I'm back to one of my first tries earlier today: a much more
> conservative change which uses fold_non_dependent_expr only for the purpose
> of suppressing the unwanted warnings, see the below.
This looks right; in general we use early
On Thu, Nov 03, 2016 at 01:55:33PM +0100, Markus Trippelsdorf wrote:
> On 2016.11.03 at 13:32 +0100, Jakub Jelinek wrote:
> > On Thu, Nov 03, 2016 at 01:22:11PM +0100, Bernd Schmidt wrote:
> > > On 11/03/2016 12:58 PM, Jakub Jelinek wrote:
> > > >On Thu, Nov 03, 2016 at 12:51:15PM +0100, Bernd Schm
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Andrew Bennett
> Sent: 03 November 2016 11:33
> To: Matthew Fortune; 'Moore, Catherine'; 'gcc-patches@gcc.gnu.org'
> Subject: RE: [PATCH] MIPS: If a test in the MIPS testsuite r
> On 08/04/2016 02:52 PM, Nathan Sidwell wrote:
> > On 08/04/16 08:27, Martin Liška wrote:
> >> Hi.
> >>
> >> Following patch is grabbed from the PR, where I just applied the patch
> >> and wrote a test-case which removes x.gcda file before running gcov tool.
> >>
> >> Ready to be installed?
> >
>
Hi all,
the attached patch restructures gfortran's way of initializing components of
derived types in ALLOCATE. The old way was to generate a new gfc_code-node and
add it after the ALLOCATE node to initialize the the derived type on certain
conditions (like initializer or allocatable components ex
On Thu, Nov 3, 2016 at 1:58 PM, Eric Botcazou wrote:
>> libfunc, as in "__{,u}divmod{di,ti}4 library function" is already
>> implemented in libgcc. But the enablement of this function inside the
>> compiler has to be performed by each target.
>
> So can we do it generically instead of duplicating
Toma Tabacu writes:
> The gcc.target/mips/wrap-delay.c test was failing on mips-img-*
> toolchains
> because it was using -mbranch-likely with an R6 target, and branch-
> likely
> instructions were removed in R6.
>
> This patch makes the testsuite downgrade to R5 if the -mbranch-likely
> option
>
On 11/03/2016 01:33 PM, Eric Botcazou wrote:
Thanks for the feedback, I'll try to work through this.
Thanks, but since there doesn't seem to be a consensus on the goal, feel free
to disregard it and just implement what you need for your initial work.
FWIW here's a more complete version of my
> On 11/03/2016 01:12 PM, Martin Liška wrote:
> >+ tree init = DECL_INITIAL (decl);
> >+ if (init
> >+ && TREE_READONLY (decl)
> >+ && can_convert_ctor_to_string_cst (init))
> >+DECL_INITIAL (decl) = build_string_cst_from_ctor (init);
>
> I'd merge these two new functions since the
> libfunc, as in "__{,u}divmod{di,ti}4 library function" is already
> implemented in libgcc. But the enablement of this function inside the
> compiler has to be performed by each target.
So can we do it generically instead of duplicating it ~50 times?
--
Eric Botcazou
On 2016.11.03 at 13:32 +0100, Jakub Jelinek wrote:
> On Thu, Nov 03, 2016 at 01:22:11PM +0100, Bernd Schmidt wrote:
> > On 11/03/2016 12:58 PM, Jakub Jelinek wrote:
> > >On Thu, Nov 03, 2016 at 12:51:15PM +0100, Bernd Schmidt wrote:
> > >>I'm concerned about the number of false positives for this w
> -Original Message-
> From: Toma Tabacu [mailto:toma.tab...@imgtec.com]
> Sent: Thursday, November 3, 2016 6:58 AM
> Subject: [PATCH,testsuite] MIPS: Downgrade R6 to R5 if tests need
> branch-likely instructions.
>
>
> gcc/testsuite/
> * gcc.target/mips/mips.exp: Add check for
On 03.11.2016 08:58, Pitchumani Sivanupandi wrote:
Most of the AVR's 8k memorydevices have only rjmp instruction, not jmp. So, it
is important to wrap around jump destination to check if it can reach backwards.
Currently link specs passes --pmem-wrap-around=xxK when mrelax and
mpmem-wrap-around
On 11/03/2016 01:12 PM, Martin Liška wrote:
+ tree init = DECL_INITIAL (decl);
+ if (init
+ && TREE_READONLY (decl)
+ && can_convert_ctor_to_string_cst (init))
+DECL_INITIAL (decl) = build_string_cst_from_ctor (init);
I'd merge these two new functions since they're only ever cal
On Thu, Nov 3, 2016 at 1:18 PM, Eric Botcazou wrote:
>> libfunc is already implemented for all targets to use, there is also:
>>
>> OPTAB_NC(sdivmod_optab, "divmod$a4", UNKNOWN)
>> OPTAB_NC(udivmod_optab, "udivmod$a4", UNKNOWN)
>>
>> in optabs.def that can probably be changed for generic expansio
On Thu, Nov 3, 2016 at 1:12 PM, Martin Liška wrote:
> Hello.
>
> This is small follow-up of the patches I sent to string folding.
> The patch transforms character array defined in an initializer to string
> constant:
>
> +const char global[] = {'a', 'b', 'c', 'd', '\0'};
>
> Apart from that, it al
Hi Richard,
I did not understand your last remark:
> That is, here (and avoid the FOR_EACH_LOOP change):
>
> @@ -580,12 +586,21 @@ vectorize_loops (void)
> && dump_enabled_p ())
> dump_printf_loc (MSG_OPTIMIZED_LOCATIONS, vect_location,
>"loop vecto
> Thanks for the feedback, I'll try to work through this.
Thanks, but since there doesn't seem to be a consensus on the goal, feel free
to disregard it and just implement what you need for your initial work.
--
Eric Botcazou
On Thu, Nov 03, 2016 at 01:22:11PM +0100, Bernd Schmidt wrote:
> On 11/03/2016 12:58 PM, Jakub Jelinek wrote:
> >On Thu, Nov 03, 2016 at 12:51:15PM +0100, Bernd Schmidt wrote:
> >>I'm concerned about the number of false positives for this warning, and
> >>judging by previous discussions, I'm not al
During Richi's debugging of the section type conflict, he found a
problem with rs6000_xcoff_declare_object_name trying to access a decl
that did not exist. Fixed thusly.
* config/rs6000/rs6000.c (rs6000_xcoff_declare_object_name): Use
symtab_node::get_create.
Index: rs6000.c
On 11/03/2016 12:58 PM, Jakub Jelinek wrote:
On Thu, Nov 03, 2016 at 12:51:15PM +0100, Bernd Schmidt wrote:
I'm concerned about the number of false positives for this warning, and
judging by previous discussions, I'm not alone in this. This patch limits it
to level 1 (any comment before the case
On 03/11/16 12:06, Eric Botcazou wrote:
What's your decision on this?
I think that we ought to standardize on a single order for note copying in the
RTL middle-end and the best way to enforce it is to have a single primitive in
rtlanal.c, with an optional filtering. Bernd's patch is a step
Fix ldrd offsets of Thumb-2 - for TARGET_LDRD the range is +-1020,
without -255..4091. This reduces the number of addressing instructions
when using DI mode operations (such as in PR77308).
Bootstrap & regress OK.
ChangeLog:
2015-11-03 Wilco Dijkstra
gcc/
* config/arm/arm.c (arm_
> libfunc is already implemented for all targets to use, there is also:
>
> OPTAB_NC(sdivmod_optab, "divmod$a4", UNKNOWN)
> OPTAB_NC(udivmod_optab, "udivmod$a4", UNKNOWN)
>
> in optabs.def that can probably be changed for generic expansion.
So what's the purpose of ix86_init_libfuncs if the lib
1 - 100 of 131 matches
Mail list logo
