Hi Jeff,
> On 9/16/18 5:28 AM, Rainer Orth wrote:
>> Currently, the libgcc-unwind.map file generated for use with Solaris ld
>>
>> http://gcc.gnu.org/ml/gcc-patches/2014-01/msg01088.html
>>
>> uses the v1 linker map file syntax because both that's supported
>> everywhere. However, with ld
On Sep 17 2018, Jeff Law wrote:
> On 9/17/18 3:08 AM, Andreas Schwab wrote:
>> PR rtl-optimization/85458
>> * sel-sched.c (sel_target_adjust_priority): Remove wrong
>> assertion.
> Under what conditions is the new priority negative? Without digging
> deep into the ia64 port that j
On 9/17/18 1:39 PM, Martin Liška wrote:
> On 9/12/18 4:48 PM, Richard Biener wrote:
>> On Wed, Sep 12, 2018 at 11:27 AM Martin Liška wrote:
>>>
>>> On 9/11/18 5:08 PM, Alexander Monakov wrote:
On Tue, 11 Sep 2018, Martin Liška wrote:
> I've discussed the topic with Alexander on the Cauldr
> Do you have any progress with this?
Once I'm done with the recent regressions, I'll get back to this older one.
--
Eric Botcazou
Hi all,
On 18/09/18 00:00, Ramana Radhakrishnan wrote:
On Mon, 17 Sep 2018, 23:56 Christophe Lyon,
wrote:
> On Fri, 14 Sep 2018 at 12:04, Sam Tebbs wrote:
> >
> >
> >
> > On 08/28/2018 11:54 PM, James Greenhalgh wrote:
> >
> >
> > >
> > > OK once the other one is approved, with the obvious r
On 13/09/18 07:49 +0200, François Dumont wrote:
All changes limited to hashtable_c++0x.cc file.
_Prime_rehash_policy::_M_next_bkt now really does what its comment was
declaring that is to say:
// Return a prime no smaller than n.
_Prime_rehash_policy::_M_need_rehash rehash only when _M_next
On 17/09/18 20:28, Richard Sandiford wrote:
This patch simply disables the cache so that it must ask the backend for the
preferred mode for every type.
TBH I'm surprised this works. Obviously it does, otherwise you wouldn't
have posted it, but it seems like an accident. Various parts of the
v
> this seems to contradict your statement above about having to work
> harder to fix up minipools.
Why? Fixing up minipools is done in the generic ARM reorg pass, not in the
Thumb reorg pass(es).
> Why do we need a barrier here unconditionally (ie in the non-longcall case)?
We don't, but it do
[PATCH][GCC][AARCH64] Use STLUR for atomic_store
Use the STLUR instruction introduced in Armv8.4-a.
This instruction has the store-release semantic like STLR but can take a
9-bit unscaled signed immediate offset.
Example test case:
```
void
foo ()
{
int32_t *atomic_vals = calloc (4, sizeof (i
Hi.
One more tested patch.
Martin
>From ee960f3dcad03652cd133b8598131aed488c11cb Mon Sep 17 00:00:00 2001
From: marxin
Date: Mon, 17 Sep 2018 10:19:02 +
Subject: [PATCH] Backport r264363
gcc/ChangeLog:
2018-09-17 Martin Liska
PR gcov-profile/85871
* gcov.c (output_intermediate_file):
This one came up on clf yesterday. Thanks to Jeurgen Reuter for posting the PR.
This is further fallout from the array descriptor changes. I decided
not to pick out the special case involved but to set the 'span' field
for all new (ie. 'parm') descriptors. A bit of fiddling around with
gfc_get_arr
> Am 17.09.2018 um 19:11 schrieb Segher Boessenkool
> :
>
> On Mon, Sep 17, 2018 at 10:50:58AM +0200, Ilya Leoshkevich wrote:
>>> Am 14.09.2018 um 23:35 schrieb Segher Boessenkool
>>> :
>>> Could you please show generated code before and after this patch?
>>> I mean generated assembler code.
On 18/09/18 10:00, Eric Botcazou wrote:
>> this seems to contradict your statement above about having to work
>> harder to fix up minipools.
>
> Why? Fixing up minipools is done in the generic ARM reorg pass, not in the
> Thumb reorg pass(es).
>
Ah! But that still doesn't explain why you want
On 9/17/18 8:41 PM, David Malcolm wrote:
> On Wed, 2018-09-12 at 14:36 +0200, Martin Liška wrote:
>> Hi.
>>
>> This is follow-up of:
>> https://gcc.gnu.org/ml/gcc/2018-08/msg00162.html
>>
>> I'm suggesting to introduce using colors in order to indicate hotness
>> of lines. Legend is printed at the
Andrew Stubbs writes:
> On 17/09/18 20:28, Richard Sandiford wrote:
>>> This patch simply disables the cache so that it must ask the backend for the
>>> preferred mode for every type.
>>
>> TBH I'm surprised this works. Obviously it does, otherwise you wouldn't
>> have posted it, but it seems li
> Am 17.09.2018 um 19:11 schrieb Segher Boessenkool
> :
>
> On Mon, Sep 17, 2018 at 10:50:58AM +0200, Ilya Leoshkevich wrote:
>>> Am 14.09.2018 um 23:35 schrieb Segher Boessenkool
>>> :
>
>>> Why does the existing jump threading not work for you; should it happen
>>> at another time?
>>
>> We
On 09/18/18 07:31, Jeff Law wrote:
> On 9/17/18 1:18 PM, Bernd Edlinger wrote:
>> On 09/17/18 20:32, Jeff Law wrote:
>>> On 9/17/18 12:20 PM, Bernd Edlinger wrote:
On 09/17/18 19:33, Jeff Law wrote:
> On 9/16/18 1:58 PM, Bernd Edlinger wrote:
>> Hi,
>>
>> this is a cleanup of t
> Am 18.09.2018 um 02:57 schrieb Jeff Law :
>
> On 9/5/18 2:34 AM, Ilya Leoshkevich wrote:
>> --- a/gcc/cfgcleanup.c
>> +++ b/gcc/cfgcleanup.c
>> @@ -2624,7 +2624,7 @@ bb_is_just_return (basic_block bb, rtx_insn **ret,
>> rtx_insn **use)
>> {
>> rtx pat = PATTERN (insn);
>>
>> -if
Hi All,
I'm looking for a backport of this patch to GCC8.
Ok for backport?
Thanks,
Tamar
> -Original Message-
> From: Kyrill Tkachov
> Sent: Wednesday, August 15, 2018 15:25
> To: Tamar Christina ; Thomas Preudhomme
>
> Cc: gcc-patches@gcc.gnu.org; nd ; Ramana Radhakrishnan
> ; Richar
On Mon, Sep 17, 2018 at 1:53 PM, Paolo Carlini wrote:
> Hi again,
>
> On 9/3/18 10:59 PM, Paolo Carlini wrote:
>>
>> in this error-recovery ICE, upon the error make_constrained_auto assigns
>> error_mark_node to PLACEHOLDER_TYPE_CONSTRAINTS (type) which then causes a
>> crash later when hash_place
Hi Tamar,
On 18/09/18 13:55, Tamar Christina wrote:
Hi All,
I'm looking for a backport of this patch to GCC8.
Ok for backport?
Ok if testing on that branch shows no problems.
Thanks,
Kyrill
Thanks,
Tamar
> -Original Message-
> From: Kyrill Tkachov
> Sent: Wednesday, August 15,
On Mon, 17 Sep 2018, Richard Biener wrote:
>
> The following fixes the memory use at -O0 from out-of-SSA coalescing
> (conflict computation in particular) with lots of abnormals (setjmp
> calls). After reviewing I found no reason to not use
> compute_optimized_partition_bases since we populate t
Hi all,
As described in https://gcc.gnu.org/ml/gcc-patches/2018-09/msg00963.html this
test generates UXTW instructions with -mabi=ilp32
because the foo* functions take pointers and store results into them. In ILP32
the callee clears the top bits with a UXTW.
This trips the scan-assembler-not UX
Hi all,
These two tests started failing after commit r264335 that adjusted the cutoff
point at which the diagnostic suggestions machinery decides a suggestion is
meaningful.
For these tests it means we no longer suggest anything as an alternative to
"armv8-a-typo" as an "arch=" pargma value. W
Hi all,
This new test has some difficulties on the fabsl function.
On arm this is because we don't support the _Float128 type which the test uses.
This is handled in the patch by requiring a float128 target selector.
On aarch64-none-elf, a Newlib target, it fails because fabsl is not available.
This ICE happens when we try and figure if an unresolved auto type is
compatible with a previous binding. With the addition of auto, we're
now checking too early, but that's a harder problem. This fixes the
ICE, but the downside is we don't warn at all, if the auto resolves to a
compatible t
On 9/18/18 1:52 AM, Andreas Schwab wrote:
> On Sep 17 2018, Jeff Law wrote:
>
>> On 9/17/18 3:08 AM, Andreas Schwab wrote:
>>> PR rtl-optimization/85458
>>> * sel-sched.c (sel_target_adjust_priority): Remove wrong
>>> assertion.
>> Under what conditions is the new priority negative?
On 9/18/18 7:45 AM, Kyrill Tkachov wrote:
> Hi all,
>
> This new test has some difficulties on the fabsl function.
> On arm this is because we don't support the _Float128 type which the
> test uses.
> This is handled in the patch by requiring a float128 target selector.
>
> On aarch64-none-elf, a
Hi Kyrill,
> This new test has some difficulties on the fabsl function.
> On arm this is because we don't support the _Float128 type which the test
> uses.
> This is handled in the patch by requiring a float128 target selector.
>
> On aarch64-none-elf, a Newlib target, it fails because fabsl is n
On Wed, Sep 05, 2018 at 10:34:48AM +0200, Ilya Leoshkevich wrote:
> S/390 epilogue ends with (parallel [(return) (use %r14)]) instead of
> the more usual (return) or (simple_return). This sequence is not
> recognized by the conditional return logic in try_optimize_cfg ().
Why does it need this?
On 18/09/18 10:15, Matthew Malcomson wrote:
> [PATCH][GCC][AARCH64] Use STLUR for atomic_store
>
> Use the STLUR instruction introduced in Armv8.4-a.
> This instruction has the store-release semantic like STLR but can take a
> 9-bit unscaled signed immediate offset.
>
> Example test case:
> ```
>
On 18/09/18 14:59, Rainer Orth wrote:
Hi Kyrill,
This new test has some difficulties on the fabsl function.
On arm this is because we don't support the _Float128 type which the test uses.
This is handled in the patch by requiring a float128 target selector.
On aarch64-none-elf, a Newlib targ
The changes to invoke.texi in r242433 left some unwanted spaces that
texi2pod.pl interprets as verbatim formatting. There are also some
grammatical errors due to the removal of references to GCJ, where the
G++ driver is referred to in the plural.
PR other/87353
* doc/invoke.texi (
On Tue, Sep 18, 2018 at 12:22:14PM +0200, Ilya Leoshkevich wrote:
>
>
> > Am 17.09.2018 um 19:11 schrieb Segher Boessenkool
> > :
> >
> > On Mon, Sep 17, 2018 at 10:50:58AM +0200, Ilya Leoshkevich wrote:
> >>> Am 14.09.2018 um 23:35 schrieb Segher Boessenkool
> >>> :
> >>> Could you please sho
On Tue, Sep 18, 2018 at 01:29:56PM +0200, Ilya Leoshkevich wrote:
> > Yeah, jump2 is quite late. I think you should do it before postreload_cse
> > or similar.
>
> Thanks, I will give it a try.
>
> > Btw, what percentage of files (or subroutines) does jump threading run
> > after combine, with y
Hi!
On Mon, Sep 17, 2018 at 11:11:53AM +0200, Eric Botcazou wrote:
> more precisely, to a nested function that requires a static chain. The
> reason
> is that the sibling call epilogue may clobber the static chain register r11.
>
> Tested on PowerPC/Linux, OK for the mainline?
>
>
> 2018-09-
On Mon, Sep 17, 2018 at 11:28:06PM -0400, Jason Merrill wrote:
> On Mon, Sep 17, 2018 at 5:39 PM, Marek Polacek wrote:
> > On Fri, Sep 14, 2018 at 04:45:22PM -0400, Marek Polacek wrote:
> >> On Fri, Sep 14, 2018 at 04:30:46PM -0400, Jason Merrill wrote:
> >> > On Fri, Sep 14, 2018 at 1:19 PM, Mare
diff --git a/gcc/config/aarch64/atomics.md b/gcc/config/aarch64/atomics.md
index
36c06756a1f94cadae097b3aad654fbeba1cf2f3..73078e412d01a43c05195f01488b95a2bc7a20ec
100644
--- a/gcc/config/aarch64/atomics.md
+++ b/gcc/config/aarch64/atomics.md
@@ -481,9 +481,9 @@
)
(define_insn "atomic_
On 18/09/18 16:36, Matthew Malcomson wrote:
>
>>> diff --git a/gcc/config/aarch64/atomics.md
>>> b/gcc/config/aarch64/atomics.md
>>> index
>>> 36c06756a1f94cadae097b3aad654fbeba1cf2f3..73078e412d01a43c05195f01488b95a2bc7a20ec
>>> 100644
>>> --- a/gcc/config/aarch64/atomics.md
>>> +++ b/gcc/config/
On 09/14/2018 12:17 PM, David Malcolm wrote:
gcc/ChangeLog:
* pretty-print.c (get_power_of_two): New function.
(struct relative_to_power_of_2): New struct.
(pp_humanized_limit): New function.
(pp_humanized_range): New function.
(selftest::assert_pp_humanize
On 08/01/2018 04:12 AM, Tom de Vries wrote:
> On 07/31/2018 05:27 PM, Cesar Philippidis wrote:
>>/* Copy the (device) pointers to arguments to the device (dp and hp might
>> in
>> fact have the same value on a unified-memory system). */
>
> This comment needs to be updated, right?
>
On Wed, 2018-09-12 at 08:23 -0500, Segher Boessenkool wrote:
> Hi!
> > + unsigned int n_elts = VECTOR_CST_NELTS (arg0);
> > + if (TREE_CODE (arg1) != INTEGER_CST
> > + || TREE_INT_CST_LOW (arg1) > (n_elts -1))
> > + return false;
>
> I think you should check lower bound 0 as well.
2018-09-18 Uros Bizjak
* config/i386/i386.md (*extendxf2): Macroize insn from
*extendsfxf2 and *extenddfxf2 using MODEF mode iterator.
Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.
Committed to mainline SVN.
Uros.
Index: config/i386/i386.md
=
Combine will put CLOBBER (with a non-void mode) anywhere in a pattern
to poison it. reg_overlap_mentioned_p did not handle this. This patch
fixes that.
Tested on the PR testcase on x86_64-linux; also bootstrapped and
regression checked on powerpc64-linux {-m32,-m64}. Is this okay for
trunk and
On 17/09/18 16:41 +0100, Jonathan Wakely wrote:
On 17/09/18 16:41 +0200, Stephan Bergmann wrote:
Compiling LibreOffice with recent GCC trunk, I came across an error
like with this reproducer
$ cat test14.cc
#include
struct S1;
struct S2;
struct D { void operator ()(S1 *); };
class C {
std:
Segher Boessenkool writes:
> Combine will put CLOBBER (with a non-void mode) anywhere in a pattern
> to poison it. reg_overlap_mentioned_p did not handle this. This patch
> fixes that.
>
> Tested on the PR testcase on x86_64-linux; also bootstrapped and
> regression checked on powerpc64-linux {-
On Tue, Sep 18, 2018 at 10:52:17AM -0500, Will Schmidt wrote:
> On Wed, 2018-09-12 at 08:23 -0500, Segher Boessenkool wrote:
> > Hi!
>
> > > + unsigned int n_elts = VECTOR_CST_NELTS (arg0);
> > > + if (TREE_CODE (arg1) != INTEGER_CST
> > > + || TREE_INT_CST_LOW (arg1) > (n_elts -1))
> > > +
On Sep 17 2018, Jeff Law wrote:
> Hmm, I thought Andreas NAK'd V1.
Consider that retracted. My misunderstanding.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
On Tue, Sep 11, 2018 at 9:01 AM, H.J. Lu wrote:
> On Tue, Sep 4, 2018 at 9:01 AM, H.J. Lu wrote:
>> On Tue, Aug 28, 2018 at 11:04 AM, H.J. Lu wrote:
>>> With -mavx, for
>>>
>>> [hjl@gnu-cfl-1 skx-2]$ cat foo.i
>>> extern float f;
>>> extern double d;
>>> extern int i;
>>>
>>> void
>>> foo (void)
On 09/17/2018 05:09 PM, Jeff Law wrote:
On 9/14/18 4:11 PM, Martin Sebor wrote:
On 09/14/2018 03:35 PM, Jeff Law wrote:
On 9/12/18 11:46 AM, Martin Sebor wrote:
On 08/31/2018 04:07 AM, Richard Biener wrote:
On Thu, Aug 30, 2018 at 7:39 PM Martin Sebor wrote:
On 08/30/2018 11:22 AM, Richard
This comment is quite cryptic and very out-of-date by now. Committing.
2018-09-18 Segher Boessenkool
* config/rs6000/rs6000.md: Remove old "Cygnus sibcall" comment.
---
gcc/config/rs6000/rs6000.md | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/gcc/config/rs60
On Fri, Aug 17, 2018 at 09:29:01AM +0200, Steven Bosscher wrote:
> On the topic of archaeology: Perhaps the time also finally has come to
> revisit this comment in rs6000.md:
>
> 13065; FIXME: This would probably be somewhat simpler if the Cygnus sibcall
> 13066; stuff was in GCC. <...>
Done in r
Hello world,
this patch generates direct calls to *GEMM when -fexternal-blas is
specified. This allows to handle arguments to conjugate and transposed
elements, which is quite a common use case.
While looking at the code, I found that the inline limit checks were not
correctly handled for cases
Hi Paul,
Bootstraps and regtests on FC28/x86_64 - OK for 8- and 9-branches?
OK. Thanks for the patch!
Regards
Thomas
Thanks Thomas,
I'll take a look at your in a few minutes.
Cheers
Paul
On 18 September 2018 at 18:50, Thomas Koenig wrote:
> Hi Paul,
>
>> Bootstraps and regtests on FC28/x86_64 - OK for 8- and 9-branches?
>
>
> OK. Thanks for the patch!
>
> Regards
>
> Thomas
--
"If you can't expl
Hi Thomas,
This fine, except for one niggle. Rather than having the blas source
in each testcase, why don't you put all the functions in a blas file
and use the dg-additional-sources mechanism?
Cheers
Paul
On 18 September 2018 at 18:46, Thomas Koenig wrote:
> Hello world,
>
> this patch gener
On Tue, Sep 18, 2018 at 11:25 AM, Marek Polacek wrote:
> On Mon, Sep 17, 2018 at 11:28:06PM -0400, Jason Merrill wrote:
>> On Mon, Sep 17, 2018 at 5:39 PM, Marek Polacek wrote:
>> > On Fri, Sep 14, 2018 at 04:45:22PM -0400, Marek Polacek wrote:
>> >> On Fri, Sep 14, 2018 at 04:30:46PM -0400, Jaso
On 9/18/18 5:44 AM, Bernd Edlinger wrote:
>>
>
> Hmm, you know, I wrote a while ago the following:
> https://gcc.gnu.org/ml/gcc-patches/2018-09/msg00411.html
>
> Where I suggested to change c_strlen parameter nonstr to a
> structure, where additional information could go.
It certainly seems bette
On Tue, Sep 18, 2018 at 02:29:16PM -0400, Jason Merrill wrote:
> > --- gcc/cp/class.c
> > +++ gcc/cp/class.c
> > @@ -9266,6 +9266,7 @@ build_vtbl_initializer (tree binfo,
> >tree vcall_index;
> >tree fn, fn_original;
> >tree init = NULL_TREE;
> > + tree idx = build_int_
Hi,
this is the 3rd version of the patch, the major change is to address Andrew’s
concern on the documentation part.
I updated the documentation of this option as following:
'-finline-only-static'
By default, GCC inlines functions without considering whether they
are static or not. T
On 9/18/18 11:12 AM, Martin Sebor wrote:
>> My bad. Sigh. CCP doesn't track copies, just constants, so there's not
>> going to be any data structure you can exploit. And I don't think
>> there's a value number you can use to determine the two objects are the
>> same.
>>
>> Hmm, let's back up a b
On 09/17/2018 03:52 AM, Jan Hubicka wrote:
On 09/11/2018 02:21 AM, Martin Liška wrote:
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -811,6 +811,10 @@ Wcoverage-mismatch
Common Var(warn_coverage_mismatch) Init(1) Warning
Warn in case profiles in -fprofile-use do not match.
+Wmissing-prof
This is sufficiently 'obvious' that I have committed the patch to
trunk as revision 264409.
My inclination is to commit it to 8-branch as well since deferred
character bugs were one of the complaints in the fortran standards
survey. OK?
Paul
2018-09-18 Paul Thomas
PR fortran/87239
*
On 09/18/2018 12:58 PM, Jeff Law wrote:
On 9/18/18 11:12 AM, Martin Sebor wrote:
My bad. Sigh. CCP doesn't track copies, just constants, so there's not
going to be any data structure you can exploit. And I don't think
there's a value number you can use to determine the two objects are the
sam
Hi Paul,
This fine, except for one niggle. Rather than having the blas source
in each testcase, why don't you put all the functions in a blas file
and use the dg-additional-sources mechanism?
Good idea, I have added this. Committed as r264411.
Regards
Thomas
Hi Tom,
Here is a link to our nvptx vector length patches on github:
https://github.com/cesarjp/gcc/tree/trunk-og8-vl-private
Specifically, the code lives in the trunk-og8-vl-private branch. There
are a couple of outstanding dependency patches:
* Teach gfortran to lower OpenACC routine dims
On 18/09/18 12:21, Richard Sandiford wrote:
Would the same be useful for GCN, or do you basically always
want a VF of 64?
Always 64; the vector size varies between 512-bit and 4096-bit, as needed.
None of this is a fundamental restriction in theory. It's just
something that needs to be fixed
Hi,
The expected codegen for this testcase with target {le} and
option -mcpu=power8 is lxvd2x and stxvd2x. It was initially
committed with contents as seen on builds for P7, which was
incorrect. Update as is appropriate.
[testsuite]
2018-09-18 Will Schmidt
PR testsuite/86952
On Tue, 2018-09-18 at 15:27 -0500, Will Schmidt wrote:
> Hi,
>
> The expected codegen for this testcase with target {le} and
> option -mcpu=power8 is lxvd2x and stxvd2x. It was initially
> committed with contents as seen on builds for P7, which was
> incorrect. Update as is appropriate.
>
> [te
Hi,
The expected codegen for this testcase with target {le} and
option -mcpu=power8 is lxvd2x and stxvd2x. It was initially
committed with contents as seen on builds for P7, which was
incorrect. Update as is appropriate.
[testsuite]
2018-09-18 Will Schmidt
PR testsuite/86592
On 09/18/2018 10:41 AM, Jonathan Wakely wrote:
On 13/09/18 07:49 +0200, François Dumont wrote:
All changes limited to hashtable_c++0x.cc file.
_Prime_rehash_policy::_M_next_bkt now really does what its comment
was declaring that is to say:
// Return a prime no smaller than n.
_Prime_rehash
On 17/09/18 10:22, Richard Sandiford wrote:
writes:
The IRA pass makes an assumption that any pseudos created after the pass begins
were created explicitly by the pass itself and therefore will have
corresponding entries in its other tables.
The GCN back-end, however, often creates additional
On Thu, 13 Sep 2018 at 11:49, Kyrill Tkachov
wrote:
>
>
> On 13/09/18 10:25, Sam Tebbs wrote:
> >
> > On 09/11/2018 04:20 PM, James Greenhalgh wrote:
> > > On Tue, Sep 04, 2018 at 10:13:43AM -0500, Sam Tebbs wrote:
> > >> Hi James,
> > >>
> > >> Thanks for the feedback. Here is an update with the
On 09/18/2018 12:58 PM, Qing Zhao wrote:
Hi,
this is the 3rd version of the patch, the major change is to address Andrew’s
concern on the documentation part.
I updated the documentation of this option as following:
'-finline-only-static'
By default, GCC inlines functions without consider
As promised at Cauldron, this patch uses %T and %G with dump_printf and
dump_printf_loc calls to eliminate calls to
dump_generic_expr (MSG_*, arg, TDF_SLIM) (via %T)
and
dump_gimple_stmt (MSG_*, TDF_SLIM, stmt, 0) (via %G)
throughout the middle-end, simplifying numerous dump callsites.
A
As I mentioned in the PR, [class.conv.fct] says "A conversion function is never
used to convert a (possibly cv-qualified) object to the (possibly cv-qualified)
same object type (or a reference to it), to a (possibly cv-qualified) base class
of that type (or a reference to it), or to (possibly cv-qu
On 9/6/18 4:36 AM, Simon Marchi wrote:
> On 2018-08-01 03:58 PM, Simon Marchi wrote:
>> This patch was tested to build binutils-gdb on GNU/Linux and macOS. It can
>> be
>> applied to the gcc repo too, after fixing some trivial merge conflicts
>> (someone
>> else will need to do it, as I don't ha
On 9/18/18 8:04 AM, Segher Boessenkool wrote:
> On Wed, Sep 05, 2018 at 10:34:48AM +0200, Ilya Leoshkevich wrote:
>> S/390 epilogue ends with (parallel [(return) (use %r14)]) instead of
>> the more usual (return) or (simple_return). This sequence is not
>> recognized by the conditional return logi
On 9/18/18 1:46 PM, Martin Sebor wrote:
> On 09/18/2018 12:58 PM, Jeff Law wrote:
>> On 9/18/18 11:12 AM, Martin Sebor wrote:
>>
My bad. Sigh. CCP doesn't track copies, just constants, so there's not
going to be any data structure you can exploit. And I don't think
there's a value
On 09/18/2018 08:11 AM, Marc Glisse wrote:
On Tue, 18 Sep 2018, François Dumont wrote:
If your concern is rather that the condition got evaluated which will
eventually slow down execution then I need to check generated code.
Any good link explaining how to have a clear view on the generated
c
80 matches
Mail list logo
