The followng fixes the data-ref code not properly checking whether it
can handle some constants.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2019-02-08 Richard Biener
PR middle-end/89223
* tree-data-ref.c (initialize_matrix_A): Fail if co
On Feb 7, 2019, Jason Merrill wrote:
> In protected_accessible_p and shared_member_p, if we're left with a
> USING_DECL after strip_using_decl, we can't give a meaningful answer,
> and should probably abort; we shouldn't get here with a dependent
> expression.
In g++.dg/lookup/using39.C, shared
On Thu, Feb 7, 2019 at 2:14 AM Martin Sebor wrote:
>
> The attached patch doesn't avoid the false positive but only improves
> the warning to make it more readable (as suggested in the PR by Richard
> for GCC 9). With the patch, for a call like:
>
>memcpy (d, s, -1);
>
> where d and s are poi
On Tue, 5 Feb 2019 at 15:44, Matthew Malcomson
wrote:
>
> These peepholes match a pair of SImode loads or stores that can be
> implemented with a single LDRD or STRD instruction.
> When compiling for TARGET_ARM, these peepholes originally created a set
> pattern in DI mode to be caught by movdi pa
Hi,
Add handling of the DW_FORM_ref_addr encoding to libbacktrace.
Committed to trunk.
Thanks,
- Tom
[libbacktrace] Handle DW_FORM_ref_addr
2019-02-08 Tom de Vries
PR libbacktrace/78063
* dwarf.c (build_address_map): Keep all parsed units.
(read_referenced_name_from
Hi,
The backtrace functions backtrace_full, backtrace_print and backtrace_simple
walk the call stack, but make sure to skip the first entry, in order to skip
over the functions themselves, and start the backtrace at the caller of the
functions.
When compiling with -flto, the functions may be inli
On Fri, Feb 8, 2019 at 12:53 AM Steve Ellcey wrote:
>
> On Thu, 2019-01-31 at 08:46 +0100, Uros Bizjak wrote:
> > On Wed, Jan 30, 2019 at 9:51 PM Janne Blomqvist
> >
> > > This seems to change the only user of support_fpu_trap() that is
> > > different from support_fpu_flag(), so with this change
Hi,
Add libbacktrace test-case using -flto.
OK for trunk?
Thanks,
- Tom
[libbacktrace] Add btest_lto
2019-02-08 Tom de Vries
* Makefile.am (BUILDTESTS): Add btest_lto.
* Makefile.in: Regenerate.
* btest.c (test1, f2, f3, test3, f22, f23): Declare with
__attr
I am working on an internal data structure overhaul in the vectorizer to
support future changes. The first task is to remove the non-SLP
representation which will simplify code and improve maintainability.
This first task is actually the most difficult and time-consuming one.
I have pushed the
On Fri, Feb 8, 2019 at 10:41 AM Tom de Vries wrote:
>
> Hi,
>
> The backtrace functions backtrace_full, backtrace_print and backtrace_simple
> walk the call stack, but make sure to skip the first entry, in order to skip
> over the functions themselves, and start the backtrace at the caller of the
Between 20181106 (r265849) and 20181107 (r265879), gnat.dg/lto19.adb
started to XPASS everywhere:
XPASS: gnat.dg/lto19.adb (test for excess errors)
Fixed as follows, tested on i386-pc-solaris2.11 and
sparc-sun-solaris2.11.
Ok for mainline?
Rainer
--
---
On Thu, 7 Feb 2019, Jakub Jelinek wrote:
> Hi!
>
> As mentioned in the PR, given that during expansion we expand ARRAY_REFs
> using get_inner_reference that casts ARRAY_*REF indexes to sizetype, all the
> bits above sizetype are ignored (whether one uses long long indexes on
> 32-bit targets or _
On Fri, Feb 08, 2019 at 10:18:03AM +0100, Christophe Lyon wrote:
> I'm afaid this patch causes several regressions. Maybe they have
> already been fixed post-commit (I have several validations for later
> commits still running)?
The following patch fixes the single ICE I've tried to reproduce.
Whi
On Thu, Feb 7, 2019 at 10:11 PM H.J. Lu wrote:
>
> OImode and TImode moves must be done in XImode to access upper 16
> vector registers without AVX512VL. With AVX512VL, we can access
> upper 16 vector registers in OImode and TImode.
>
> PR target/89229
> * config/i386/i386.md (*mo
> The following testcase ICEs on ppc64le. The problem is that
> copy_reg_eh_region_note_* functions accept either some instruction, or
> REG_EH_REGION note directly. To differentiate between those it uses INSN_P
> test (and returns early if the insn doesn't contain any REG_EH_REGION
> notes). If
On Fri, 8 Feb 2019 at 10:51, Jakub Jelinek wrote:
>
> On Fri, Feb 08, 2019 at 10:18:03AM +0100, Christophe Lyon wrote:
> > I'm afaid this patch causes several regressions. Maybe they have
> > already been fixed post-commit (I have several validations for later
> > commits still running)?
>
> The f
> Between 20181106 (r265849) and 20181107 (r265879), gnat.dg/lto19.adb
> started to XPASS everywhere:
>
> XPASS: gnat.dg/lto19.adb (test for excess errors)
The idea was to wait until Jan fixes the lto8 failure introduced roughly at
the same time...
--
Eric Botcazou
On Fri, Feb 08, 2019 at 10:48:30AM +0100, Richard Biener wrote:
> > --- gcc/gimplify.c.jj 2019-01-28 23:30:53.199762928 +0100
> > +++ gcc/gimplify.c 2019-02-06 17:15:35.368976785 +0100
> > @@ -2977,6 +2977,12 @@ gimplify_compound_lval (tree *expr_p, gi
> >
> >if (TREE_CODE (t) == A
On Fri, Feb 08, 2019 at 11:06:02AM +0100, Christophe Lyon wrote:
> On Fri, 8 Feb 2019 at 10:51, Jakub Jelinek wrote:
> >
> > On Fri, Feb 08, 2019 at 10:18:03AM +0100, Christophe Lyon wrote:
> > > I'm afaid this patch causes several regressions. Maybe they have
> > > already been fixed post-commit
> Backporting this is okay. (It was not done because it does not affect
> correctness). What is the "almost", btw?
The predicate of operand #0 of movdi_internal32 is rs6000_nonimmediate_operand
on the 7 branch and nonimmediate_operand on the 8 branch and later.
> (In https://gcc.gnu.org/ml/gcc
This is a regression present on all active branches: in some cases, you get
bogus profile mismatches with -fprofile-{generate,use} at -O2 because some -O3
optimizations are automatically enabled by -fprofile-use.
Tested on x86_64-suse-linux, applied on all active branches.
2019-02-08 Eric Bot
This is a regression present on the mainline and 8 branch: in some specific
circumstances, you can get a crash when max_size is called from the gimplifier
on very dynamic record types. This makes the function a bit more robust.
Tested on x86_64-suse-linux, applied on mainline and 8 branch.
20
On 08/02/19 10:23, Jakub Jelinek wrote:
> On Fri, Feb 08, 2019 at 11:06:02AM +0100, Christophe Lyon wrote:
>> On Fri, 8 Feb 2019 at 10:51, Jakub Jelinek wrote:
>>>
>>> On Fri, Feb 08, 2019 at 10:18:03AM +0100, Christophe Lyon wrote:
I'm afaid this patch causes several regressions. Maybe they
On Fri, Feb 8, 2019 at 1:51 AM Uros Bizjak wrote:
>
> On Thu, Feb 7, 2019 at 10:11 PM H.J. Lu wrote:
> >
> > OImode and TImode moves must be done in XImode to access upper 16
> > vector registers without AVX512VL. With AVX512VL, we can access
> > upper 16 vector registers in OImode and TImode.
>
This is not really a regression (or maybe a very old one) but the behavior of
the compiler is a bit annoying so IMO worth fixing: when you put a size clause
to silence the warning about an unchecked conversion from a small type to a
(very) large one, the compiler effectively disregards the claus
On Fri, Feb 08, 2019 at 11:29:10AM +, Matthew Malcomson wrote:
> I'm pretty sure there's no difference between the iwmmxt target and
> others so believe your simpler fix of just using 'q' is a good idea.
> (there's no difference in gas and no documentation I have found mentions
> a difference
On Fri, 8 Feb 2019, Jakub Jelinek wrote:
> On Fri, Feb 08, 2019 at 10:48:30AM +0100, Richard Biener wrote:
> > > --- gcc/gimplify.c.jj 2019-01-28 23:30:53.199762928 +0100
> > > +++ gcc/gimplify.c2019-02-06 17:15:35.368976785 +0100
> > > @@ -2977,6 +2977,12 @@ gimplify_compound_lval (tr
On Fri, Feb 08, 2019 at 11:13:50AM +1030, Alan Modra wrote:
> PR target/88343
> * config/rs6000/rs6000.c (save_reg_p): Correct calls_eh_return
> case. Match logic in rs6000_emit_prologue emitting pic_offset_table
> setup, simplifying ABI_V4 case to df_regs_ever_live_p.
Tha
Tested on x86_64-unknown-linux-gnu, applied.
Richard.
2019-02-08 Richard Biener
PR testsuite/89250
* gcc.dg/vect/vect-24.c: Remove XFAIL on vect_condition targets.
Index: gcc/testsuite/gcc.dg/vect/vect-24.c
===
On Fri, Feb 08, 2019 at 12:47:08PM +0100, Richard Biener wrote:
> My worry is that while we know the IV i doesn't wrap we
> don't know the same for (sizetype)i in
>
> for (__int128 i = 0; i < n; ++i)
> a[i] = 0.;
First of all, for normal targets I think it is very rare that people use
__int128
Hello,
Below is a description of a very annoying bug we are witnessing
on ARM. I have ideas of possible ways to address it, but don't yet
have a patch.
The problem touches the synchronization of register elimination,
dataflow analysis and arm_expand_prologue. The overall logic is pretty
intricate
On 07.02.19 11:09, Ilya Leoshkevich wrote:
> Bootstrapped and regtested on s390x-redhat-linux.
>
> Implementation of section anchors in S/390 back-end added in r266741
> broke jump labels in S/390 Linux kernel [1]. Currently jump labels
> pass global variable addresses to .quad directive in inlin
On 07.02.19 10:28, Robin Dapp wrote:
> Hi,
>
> this patch implements vector copysign using vector select on S/390.
>
> Regtested and bootstrapped on s390x.
>
> Regards
> Robin
>
> --
>
> gcc/ChangeLog:
>
> 2019-02-07 Robin Dapp
>
> * config/s390/vector.md: Implement vector copysign
Hello!
Attached patch fixes --enable-frame-pointer handling, and this way
makes a couple of defines in config/i386/sol2.h obsolete.
2019-02-08 Uroš Bizjak
PR target/89221
* config.gcc (i[34567]86-*-*, x86_64-*-*): Move tests for enable_cld
and enable_frame_pointer ...
* config
The following fixes LOOP_VECTORIZED IFNs made useless by CFG cleanup
after if-conversion by re-verifying the mentioned loops still exist.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
2019-02-08 Richard Biener
PR tree-optimization/89247
* tree-if-c
expand_constructor has
if ((TREE_STATIC (exp)
&& ((mode == BLKmode
&& ! (target != 0 && safe_from_p (target, exp, 1)))
|| TREE_ADDRESSABLE (exp)
|| (tree_fits_uhwi_p (TYPE_SIZE_UNIT (type))
&& (! can_move_by_pieces
On 07/02/19 23:35 -0500, Tom Honermann wrote:
On 2/7/19 4:44 AM, Jonathan Wakely wrote:
On 23/12/18 21:27 -0500, Tom Honermann wrote:
Attached is a revised patch that addresses changes in P0482R6.
Changes from the prior patch include:
- Updated the value of the __cpp_char8_t feature test macr
Hi Olivier,
> Below is a description of a very annoying bug we are witnessing
> on ARM.
...
> compiled with -Og -mapcs
Do you know -mapcs has been deprecated for more than 4 years now?
Is there a reason you are still using it? It was deprecated since -mapcs
is both extremely inefficient and buggy
On 2019-02-07 3:09 p.m., Jakub Jelinek wrote:
> On Thu, Feb 07, 2019 at 03:04:21PM -0500, Michael Ploujnikov wrote:
>> 2019-02-07 Michael Ploujnikov
>>
>> PR middle-end/89150
>> * bitmap.c (test_bitmap_tree_marking): New test.
>> (NOT_NULL_OR_GARBAGE): For shortening
>> test_
On Fri, Feb 08, 2019 at 10:02:27AM -0500, Michael Ploujnikov wrote:
> On 2019-02-07 3:09 p.m., Jakub Jelinek wrote:
> > On Thu, Feb 07, 2019 at 03:04:21PM -0500, Michael Ploujnikov wrote:
> >> 2019-02-07 Michael Ploujnikov
> >>
> >>PR middle-end/89150
> >>* bitmap.c (test_bitmap_tree_mar
Missed two more conditional branches created by inline expansion that should
have had
branch probability notes.
2019-02-08 Aaron Sawdey
* config/rs6000/rs6000-string.c (expand_compare_loop,
expand_block_compare): Insert REG_BR_PROB notes in inline expansion of
memcmp/s
On Fri, Feb 08, 2019 at 11:46:37AM +0100, Eric Botcazou wrote:
> > Backporting this is okay. (It was not done because it does not affect
> > correctness). What is the "almost", btw?
>
> The predicate of operand #0 of movdi_internal32 is
> rs6000_nonimmediate_operand
> on the 7 branch and nonim
On Fri, Feb 08, 2019 at 10:19:40PM +1030, Alan Modra wrote:
> That one regressed gcc.dg/20020312-2.c, due to my "cleverness" in
> simplifying the ABI_V4 case. This one passes regression testing.
> OK to apply?
I think this is correct. Thanks! Okay for trunk. Does it need backports?
Segher
> On 8 Feb 2019, at 16:16, Segher Boessenkool
> wrote:
>
> On Fri, Feb 08, 2019 at 10:19:40PM +1030, Alan Modra wrote:
>> That one regressed gcc.dg/20020312-2.c, due to my "cleverness" in
>> simplifying the ABI_V4 case. This one passes regression testing.
>> OK to apply?
>
> I think this is
Hi Wilco,
> On 8 Feb 2019, at 15:49, Wilco Dijkstra wrote:
>
> Hi Olivier,
>
>> Below is a description of a very annoying bug we are witnessing
>> on ARM.
> ...
>> compiled with -Og -mapcs
>
> Do you know -mapcs has been deprecated for more than 4 years now?
> Is there a reason you are still u
On Fri, Feb 08, 2019 at 04:18:52PM +, Iain Sandoe wrote:
>
> > On 8 Feb 2019, at 16:16, Segher Boessenkool
> > wrote:
> >
> > On Fri, Feb 08, 2019 at 10:19:40PM +1030, Alan Modra wrote:
> >> That one regressed gcc.dg/20020312-2.c, due to my "cleverness" in
> >> simplifying the ABI_V4 case.
pr80887.c expects int size to be at least 32-bits, added the corresponding
require-effective-target directive.
Committed.
>From b8a747181ed83adfb0ff5f42ba74f1bc239620d8 Mon Sep 17 00:00:00 2001
From: jozefl
Date: Fri, 8 Feb 2019 16:47:28 +
Subject: [PATCH] 2019-02-08 Jozef Lawrynowicz
PR
On 08/02/2019 16:19, Olivier Hainque wrote:
> Hi Wilco,
>
>> On 8 Feb 2019, at 15:49, Wilco Dijkstra wrote:
>>
>> Hi Olivier,
>>
>>> Below is a description of a very annoying bug we are witnessing
>>> on ARM.
>> ...
>>> compiled with -Og -mapcs
>>
>> Do you know -mapcs has been deprecated for mor
Ping
On Fri, 2019-01-25 at 15:02 -0500, David Malcolm wrote:
> On Fri, 2019-01-25 at 08:59 -0800, Nathan Sidwell wrote:
> > On 1/25/19 8:48 AM, David Malcolm wrote:
> > > PR c++/89036 reports an ICE due to this assertion failing
> > >
> > > 1136/* A class should never have more than one
>
r256999 removed early bailout for pointer-to-member-function types, so we
now try to tsubst each element of a pointer-to-member-function CONSTRUCTOR.
That's fine but the problem here is that we end up converting a null pointer
to pointer-to-member-function type and that crashes in fold_convert:
1
Hi Tom!
On Fri, 8 Feb 2019 10:41:47 +0100, Tom de Vries wrote:
> The backtrace functions backtrace_full, backtrace_print and backtrace_simple
> walk the call stack, but make sure to skip the first entry, in order to skip
> over the functions themselves, and start the backtrace at the caller of th
Hi!
The following testcase distilled from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739#c0
aborts on s390x-linux when compiled with trunk -O2 with r268332 reverted (or
e.g. with -O2 and gcc 7.x) and succeeds with trunk -O2, or -O0 with any of
those compilers. Tested also on x86_64-linux wit
On Fri, 2019-02-08 at 10:42 +0100, Uros Bizjak wrote:
> so, the reverted patch neglected this assumption. Ignoring this, we
> can use
>
> --cut here--
> Index: libgfortran/config/fpu-glibc.h
> ===
> --- libgfortran/config/fpu-glibc.h
On February 8, 2019 7:22:48 PM GMT+01:00, Jakub Jelinek
wrote:
>Hi!
>
>The following testcase distilled from
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739#c0
>aborts on s390x-linux when compiled with trunk -O2 with r268332
>reverted (or
>e.g. with -O2 and gcc 7.x) and succeeds with trunk -O
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88560
The patch was bootstrapped and tested on x86-64 and ppc64. It was
also tested on ARM by Tamar Christina. The patch changes expected
generated code for one test on ppc64 but in a better way. I'll send a
patch f
Recently I committed a patch solving
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88560
The patch resulted in test vsx-simode2.c failure. Here is the
difference in generated code:
@@ -13,9 +13,8 @@ foo:
.LFB0:
.cfi_startproc
std 3,-16(1)
- ori 2,2,0
- lwz 9,-12(1
Hi Lokesh,
Sorry for not getting back to you earlier.
On Thu, Jan 10, 2019 at 05:57:52PM +0530, Lokesh Janghel wrote:
> Find the attached patch for the subjected issue.
> Please let me know your thoughts and comments on the same.
>
> >Do you have a copyright assignment with the FSF?
> We don't h
The attached patch attempts a substring length simplification
so that more complex expressions are handled in initialization
expressions. Thanks to Thomas König for the suggestion.
Regtested on x86_64-pc-linux-gnu.
(The PR still has other wrong-code issue to be addressed separately.)
OK for tru
On Fri, 8 Feb 2019 at 20:00, Richard Biener wrote:
>
> On February 8, 2019 7:22:48 PM GMT+01:00, Jakub Jelinek
> wrote:
> >Hi!
> >
> >The following testcase distilled from
> >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739#c0
> >aborts on s390x-linux when compiled with trunk -O2 with r268332
Hi Olivier,
> Sorry, I had -mapcs-frame in mind.
That's identical to -mapcs, and equally deprecated. It was superceded 2 decades
ago. -mpcs-frame bugs have been reported multiple times, including on VxWorks.
For example https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64379 suggests
VxWorks doesn't n
On 2/8/19 4:07 AM, Alexandre Oliva wrote:
On Feb 7, 2019, Jason Merrill wrote:
In protected_accessible_p and shared_member_p, if we're left with a
USING_DECL after strip_using_decl, we can't give a meaningful answer,
and should probably abort; we shouldn't get here with a dependent
expression
On 2/8/19 1:58 AM, Alexandre Oliva wrote:
On Feb 7, 2019, Jason Merrill wrote:
+ PR c++/86322. */
Wrong PR number.
Thanks
+ if (local_specializations)
+if (tree r = retrieve_local_specialization (t))
+ return r;
Hmm, I would expect this to do the wrong thing for pack
On 2/8/19 12:21 PM, Marek Polacek wrote:
r256999 removed early bailout for pointer-to-member-function types, so we
now try to tsubst each element of a pointer-to-member-function CONSTRUCTOR.
That's fine but the problem here is that we end up converting a null pointer
to pointer-to-member-functio
Hi Alan,
On Fri, Feb 08, 2019 at 11:05:57AM +1030, Alan Modra wrote:
> Inline PLT calls need PLT to be an array of addresses. bss-plt works
> differently.
>
> Bootstrap and regression test on powerpc64-linux biarch in progress.
> OK assuming no regressions?
>
> * config/rs6000/rs6000.c (r
When -march=native is passed to host_detect_local_cpu to the backend,
it overrides all command lines after it. That means
$ gcc -march=native -march=skylake-avx512
is the treated as
$ gcc -march=skylake-avx512 -march=native
Prune joined switches with negation to allow -march=skylake-avx512 to
On 07.02.19 06:04, Ian Lance Taylor wrote:
> On Thu, Jan 31, 2019 at 7:40 AM Svante Signell
> wrote:
>>
>> As advised by the Debian gcc maintainer Matthias Klose and golang
>> developer Ian Lance Taylor I'm re-submitting the patches for
>> the port of gccgo to GNU/Hurd again. Now GOOS value is ch
On Fri, Feb 8, 2019 at 3:02 PM H.J. Lu wrote:
>
> When -march=native is passed to host_detect_local_cpu to the backend,
> it overrides all command lines after it. That means
>
> $ gcc -march=native -march=skylake-avx512
>
> is the treated as
>
> $ gcc -march=skylake-avx512 -march=native
>
> Prune
Hi!
Non-type template arguments are constant-expression in the grammar and thus
manifestly constant-evaluated.
For e.g. class templates, convert_nontype_argument is called with
tf_warning_or_error and so while we called in the below spots
maybe_constant_value without manifestly_const_eval=true, th
In the standard these member functions are specified in terms of the
potentially-throwing path decompositions functions, but we implement
them without constructing any new paths or doing anything else that can
throw.
PR libstdc++/71044
* include/bits/fs_path.h (path::has_root_name
On Fri, Feb 8, 2019 at 3:28 AM H.J. Lu wrote:
>
> On Fri, Feb 8, 2019 at 1:51 AM Uros Bizjak wrote:
> >
> > On Thu, Feb 7, 2019 at 10:11 PM H.J. Lu wrote:
> > >
> > > OImode and TImode moves must be done in XImode to access upper 16
> > > vector registers without AVX512VL. With AVX512VL, we can
Using #include "..." to include a header in the same directory fails if
the user compiles with -I-, so always use something like for
internal headers.
I haven't added tests for this, because dg-options adds options to the
end, and the position of -I- matters (if it's at the end then the tests
wo
hi all,
I have a patch about libstdc++
include/std/type_traits ,
testsuite/20_util/logical_traits/requirements/explicit_instantiation.cc
testsuite/20_util/logical_traits/requirements/typedefs.cc
testsuite/20_util/logical_traits/value.cc,
the patch want to add new logical traits , such as exc
(removing gcc-testresults@ which is for (automated) results of running the
testsuite, not for patch submission)
On Sat, 9 Feb 2019, 李苏旺 wrote:
I have a patch about libstdc++
include/std/type_traits ,
testsuite/20_util/logical_traits/requirements/explicit_instantiation.cc
testsuite/20_util/
73 matches
Mail list logo
