Hi,
This configuration is no longer buildable as support was removed from
gcc in r263506.
OK for trunk?
--
Iain
---
contrib/ChangeLog:
2019-04-27 Iain Buclaw
* config-list.mk (LIST): Remove rs6000-ibm-aix5.3.0.
---
diff --git a/contrib/config-list.mk b/contrib/config-list.mk
Hi,
This is the draft patch avoiding scaling cost overflow by introducing a scaling
bound
in IVOPTs. For now the bound is 20, and scaling factor will be further scaled
wrto
this bound. For example, scaling factor like 1, 1000, 2000(max) would be
scaled to
1, 10, 20 correspondingly.
HI
On Fri, Apr 26, 2019 at 2:44 PM Kewen.Lin wrote:
>
> Hi Segher,
>
> Thanks a lot for your comments!
>
> on 2019/4/25 下午8:16, Segher Boessenkool wrote:
>
> > Does it create worse code now? What we have before your patch isn't
> > so super either (it has an sldi in the loop, it has two mtctr too).
Thanks very much for working on this.
On Wed, Apr 24, 2019 at 4:41 PM Kewen.Lin wrote:
>
> Hi all,
>
> As PR80791 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80791, on
> some targets which support low-overhead loop, the related compare
> type ivs use is possible to become dead and removed
This improves optimization of code storing constants to memory. Given this
testcase:
void sub1 (int *a, long long *b) { *a = 1; *b = 1; }
an unpatched rv64 compiler emits two li instructions, one for an SImode pseudo
and one for a DImode pseudo. With the patch, we get a single DImode li
On Fri, Apr 26, 2019 at 11:30:47PM +0100, Richard Earnshaw (lists) wrote:
> A subreg on a reg is fine (which is what we'd have in this specific
> case). It's when the subreg gets left on something else (other than a
> mem) when the problems start.
Yeah. We typically push the subregs as far
On Fri, Apr 26, 2019 at 03:54:49PM -0600, Jeff Law wrote:
> > It makes most sense if the mode for extv is the same both in and out
> > (it has only one mode in the pattern name, to start with), and for
> > sign_extract to be similar. The docs aren't quite clear, but defining it
> > to have
On 4/26/19 4:30 PM, Richard Earnshaw (lists) wrote:
>>> It makes most sense if the mode for extv is the same both in and out
>>> (it has only one mode in the pattern name, to start with), and for
>>> sign_extract to be similar. The docs aren't quite clear, but defining it
>>> to have multiple
On 26/04/2019 22:54, Jeff Law wrote:
> On 4/26/19 3:09 PM, Segher Boessenkool wrote:
>> On Fri, Apr 26, 2019 at 06:06:37PM +0100, Richard Earnshaw (lists) wrote:
>>> On 26/04/2019 17:08, Jeff Law wrote:
> So is that valid RTL (DI extract of SI value)? Why wouldn't that just
> use a
On 4/26/19 3:09 PM, Segher Boessenkool wrote:
> On Fri, Apr 26, 2019 at 06:06:37PM +0100, Richard Earnshaw (lists) wrote:
>> On 26/04/2019 17:08, Jeff Law wrote:
So is that valid RTL (DI extract of SI value)? Why wouldn't that just
use a paradoxical subreg to widen the register being
On Fri, Apr 26, 2019 at 06:06:37PM +0100, Richard Earnshaw (lists) wrote:
> On 26/04/2019 17:08, Jeff Law wrote:
> >> So is that valid RTL (DI extract of SI value)? Why wouldn't that just
> >> use a paradoxical subreg to widen the register being extracted?
> > [ ... ]
> > And for completeness,
On 26 April 2019 14:07:20 CEST, Richard Biener
wrote:
>On Fri, Apr 26, 2019 at 11:26 AM Martin Liška wrote:
>>
>> Hi.
>>
>> We do have vec<...>::is_empty function, but not for
>hash_{table,map,set}.
>> Would you mind adding the function and using it? If so, I can prepare
>> a complete patch
On 26 April 2019 16:08:19 CEST, Gerald Pfeifer wrote:
>On Fri, 26 Apr 2019, Martin Liška wrote:
>> The patch clarifies that gcc-patches mailing list allows up to 400kB
>> size of an email.
>
>Thanks, yes.
Maybe drop references to gcc-prs while at it as:
ping
On 13/04/2019 10:01, Harald van Dijk wrote:
Hi,
For PR60531, GCC wrongly rejects function templates with explicitly
specified template arguments as overloaded. They are resolved by
resolve_nondeduced_context, which is normally called by
cp_default_conversion through decay_conversion, but
On Fri, Apr 26, 2019 at 07:51:05PM +0200, Richard Biener wrote:
> On April 26, 2019 6:59:43 PM GMT+02:00, Segher Boessenkool
> wrote:
> >So, make it a doloop in gimple, and still have the rtl pass, but that
> >only reverts it to a non-doloop if it turns out it has to. Does that
> >sound like a
On April 26, 2019 6:59:43 PM GMT+02:00, Segher Boessenkool
wrote:
>On Fri, Apr 26, 2019 at 10:26:52PM +0800, Kewen.Lin wrote:
>> on 2019/4/26 下午3:16, Richard Biener wrote:
>> > We should think about possible ways of encoding doloop at IVOPTs
>> > time rather than trying to re-analyze at RTL. I
Hi Manfred,
I took a look at it and couldn't see what the problem is. I'll have
another stab at it tomorrow morning.
Cheers
Paul
On Fri, 26 Apr 2019 at 16:39, Manfred Schwarb wrote:
>
> Hi,
>
> I still see this issue on 32bit, is the plan to let
> the test ISO_Fortran_binding_4.f90 be broken
> So just an FYI. If ddg.c is only used by the modulo scheduler, then it
> falls under your maintainership and you can decide when to install this
> patch.
Yes, I understand about ddg.c and ddg.h. I also studied everything
about loop-doloop.c because it is connected. Will try to participate
in
AIX doesn't allow calling mmap on an address range which is already
mmap. Therefore, once the region has been allocated, it must munmap
before being able to use it. This patch by Clément Chigot does that
in libgo. Bootstrapped on x86_64-pc-linux-gnu. Committed to
mainline.
Ian
Index:
On 26/04/19 18:44 +0200, Jakub Jelinek wrote:
On Fri, Apr 26, 2019 at 03:05:36PM +0100, Jonathan Wakely wrote:
Jakub noted in https://gcc.gnu.org/ml/libstdc++/2019-04/msg00140.html
that an unwanted std::wstring::_M_replace_dispatch symbol has started to
be exported from the Fedora
On 26/04/2019 17:08, Jeff Law wrote:
> On 4/26/19 8:52 AM, Richard Earnshaw (lists) wrote:
>> On 26/04/2019 15:13, Jeff Law wrote:
>>> On 4/16/19 10:29 AM, Steve Ellcey wrote:
Re-ping. I know there are discussions about bigger changes to fix the
various failures listed in PR
On Fri, Apr 26, 2019 at 10:26:52PM +0800, Kewen.Lin wrote:
> on 2019/4/26 下午3:16, Richard Biener wrote:
> > We should think about possible ways of encoding doloop at IVOPTs
> > time rather than trying to re-analyze at RTL. I suppose we can
> > easily set a flag in struct loop but I'm not familiar
On 26/04/19 18:41 +0200, Jakub Jelinek wrote:
On Fri, Apr 26, 2019 at 09:38:45AM -0700, H.J. Lu wrote:
Here is the patch for x32. OK for trunk and for 9.1?
If Jonathan approves it, it is ok also for 9.1.
Yes, it looks fine - OK for trunk and 9.1 - thanks.
On Fri, Apr 26, 2019 at 03:05:36PM +0100, Jonathan Wakely wrote:
> Jakub noted in https://gcc.gnu.org/ml/libstdc++/2019-04/msg00140.html
> that an unwanted std::wstring::_M_replace_dispatch symbol has started to
> be exported from the Fedora shared library. This symbol is triggered by
On Fri, Apr 26, 2019 at 02:43:44PM +0800, Kewen.Lin wrote:
> > Does it create worse code now? What we have before your patch isn't
> > so super either (it has an sldi in the loop, it has two mtctr too).
> > Maybe you can show the generated code?
>
> It's a good question! From the generated codes
On Fri, Apr 26, 2019 at 04:02:00PM +0100, Jonathan Wakely wrote:
> The pmr::string typedef isn't available for the old COW string, so some
> tests that use it were failing.
>
> * testsuite/20_util/variant/run.cc: Use a new Hashable type to test
> hashing, because pmr::string depends
On Fri, Apr 26, 2019 at 09:38:45AM -0700, H.J. Lu wrote:
> Here is the patch for x32. OK for trunk and for 9.1?
If Jonathan approves it, it is ok also for 9.1.
Jakub
Hello, Jeff
> > As a freshly appointed maintainer I’m ready to commit my own
> > modulo-sched patches, but decide to ask here if there are any
> > objections. Maybe I should ask any additional approval at this stage?
> > If no, I’ll start tomorrow with committing patches 1/4 and 2/4 which are
>
On Fri, Apr 26, 2019 at 8:59 AM Jonathan Wakely wrote:
>
> On 26/04/19 15:05 +0100, Jonathan Wakely wrote:
> >On 26/04/19 14:36 +0100, Jonathan Wakely wrote:
> >>On 26/04/19 14:30 +0200, Jakub Jelinek wrote:
> >>>On Fri, Apr 26, 2019 at 01:25:37PM +0100, Jonathan Wakely wrote:
> On 26/04/19
On Thu, Apr 25, 2019 at 6:47 PM Jonathan Wakely wrote:
> On 25/04/19 17:02 -0400, Jason Merrill wrote:
> >Perhaps initialize show_notes to (complain & tf_error), so you only
> >need to update it from permerror.
>
> But doesn't fix the bug, because the error is only printed for
>
On 4/26/19 8:52 AM, Richard Earnshaw (lists) wrote:
> On 26/04/2019 15:13, Jeff Law wrote:
>> On 4/16/19 10:29 AM, Steve Ellcey wrote:
>>> Re-ping. I know there are discussions about bigger changes to fix the
>>> various failures listed in PR rtl-optimization/87763 but this patch
>>> at least
On 26/04/19 15:05 +0100, Jonathan Wakely wrote:
On 26/04/19 14:36 +0100, Jonathan Wakely wrote:
On 26/04/19 14:30 +0200, Jakub Jelinek wrote:
On Fri, Apr 26, 2019 at 01:25:37PM +0100, Jonathan Wakely wrote:
On 26/04/19 12:48 +0200, Jakub Jelinek wrote:
Hi!
The following patch updates the
On 4/18/19 6:47 AM, Eugene Sharygin wrote:
> Hi,
>
> This silences UnicodeDecodeError Python exceptions raised when trying to
> print a tree with a corrupt (or uninitialized) code in Gdb:
>
> Python Exception 'utf-8' codec can't decode
> byte 0xb8 in position 0: invalid start byte:
>
>
Hi!
On Fri, Apr 26, 2019 at 09:31:36AM -0600, Jeff Law wrote:
> > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
Thanks, committed to trunk now.
> > I'll work on a C++ FE version of this next (needed as well).
Here is the C++ FE version of this patch,
On 4/22/19 10:45 AM, Roman Zhuykov wrote:
> As a freshly appointed maintainer I’m ready to commit my own
> modulo-sched patches, but decide to ask here if there are any
> objections. Maybe I should ask any additional approval at this stage?
> If no, I’ll start tomorrow with committing patches
Hi,
I still see this issue on 32bit, is the plan to let
the test ISO_Fortran_binding_4.f90 be broken for the 9.0 release?
Cheers,
Manfred
Am 15.04.19 um 10:30 schrieb Dominique d'Humières:
> Hi Paul,
>
> I have found another glitch with -m32 and -O1 or -Os, but not with other
> values:
>
> %
On 4/16/19 6:05 AM, Roman Zhuykov wrote:
> Current algorithm which finds recurrence_length for all DDG strongly
> connected components works in like O(N^6) time, where N in the number of
> nodes in DDG. The time is so bad mostly for graphs with lots of edges,
> like almost N^2 edges. My proposed
On 4/24/19 7:29 AM, Ian Lance Taylor via gcc-patches wrote:
> On Mon, Apr 22, 2019 at 11:51 PM Michael Forney wrote:
>>
>> This matches how the the rest of the libc functions are declared and
>> prevents a potential conflict with the system declaration when libiberty.h
>> is included from a
On 4/25/19 3:13 AM, Jakub Jelinek wrote:
> Hi!
>
> The introduction of -gstatement-frontiers (and making it the default)
> regressed debug info experience on the attached testcases (not including
> in the testsuite, as not sure how to model that in the guality testsuite).
> The current behavior
On 4/26/19 5:02 AM, Martin Liška wrote:
> Hi.
>
> The fix is about forgotten target options for which get_valid_option_values
> returns empty list.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed to trunk and later than to gcc-9 branch?
>
On 26/04/19 16:18 +0100, Jonathan Wakely wrote:
On 26/04/19 08:59 +0200, Richard Biener wrote:
On Thu, Apr 25, 2019 at 11:31 PM Jonathan Wakely wrote:
PR libstdc++/90239
* doc/xml/manual/status_cxx2020.xml: Correct status of P0591R4.
* doc/html/*: Regenerate.
This
On 26/04/19 08:59 +0200, Richard Biener wrote:
On Thu, Apr 25, 2019 at 11:31 PM Jonathan Wakely wrote:
PR libstdc++/90239
* doc/xml/manual/status_cxx2020.xml: Correct status of P0591R4.
* doc/html/*: Regenerate.
This corrects the docs to reflect the real status in
On Fri, Apr 12, 2019 at 05:24:26PM -0400, Jason Merrill wrote:
> If a noexcept function calls a function that might throw, doing the tail
> call optimization means that an exception thrown in the called function
> will propagate out, breaking the noexcept specification. So we need to
> prevent
The pmr::string typedef isn't available for the old COW string, so some
tests that use it were failing.
* testsuite/20_util/variant/run.cc: Use a new Hashable type to test
hashing, because pmr::string depends on _GLIBCXX_USE_CXX11_ABI==1.
*
On 4/26/19 8:52 AM, Richard Earnshaw (lists) wrote:
> On 26/04/2019 15:13, Jeff Law wrote:
>> On 4/16/19 10:29 AM, Steve Ellcey wrote:
>>> Re-ping. I know there are discussions about bigger changes to fix the
>>> various failures listed in PR rtl-optimization/87763 but this patch
>>> at least
On 26/04/2019 15:13, Jeff Law wrote:
> On 4/16/19 10:29 AM, Steve Ellcey wrote:
>> Re-ping. I know there are discussions about bigger changes to fix the
>> various failures listed in PR rtl-optimization/87763 but this patch
>> at least fixes one of them (gcc.target/aarch64/lsl_asr_sbfiz.c).
>>
>>
On 4/25/19 7:14 PM, Paolo Carlini wrote:
Hi,
On 25/04/19 23:14, Jason Merrill wrote:
On Tue, Apr 23, 2019 at 11:26 AM Paolo Carlini
wrote:
I tried a few different things to avoid this simple error-recovery
regression but, all in all, I think it makes sense to simply bail out
early from
on 2019/4/26 下午3:16, Richard Biener wrote:
> On Fri, 26 Apr 2019, Kewen.Lin wrote:
>
>> I was thinking whether this zero cost change just exposed
>> an existing problem, then this kind of check should be for all
>> cases not only for zero cost use, similar to
>> expression_expensive_p? But
On 4/26/19 2:01 AM, Jakub Jelinek wrote:
> On Fri, Apr 26, 2019 at 08:58:18AM +0200, Richard Biener wrote:
>> On Thu, Apr 25, 2019 at 7:52 PM James Clarke wrote:
>>>
>>> By using ASM_OUTPUT_LABEL, r257511 forced the assembler to start a new
>>> bundle when emitting an inline entry label on.
I reverted r270484 for GCC 9 (as approved by the RMs on irc). This
is r270601. I left the new testcase to reduce churn.
[ I tried to reply to the thread, but the mail archive has no way of
sending the original message (if you try it sends a digest instead),
so I cannot figure out the message
On 4/16/19 10:29 AM, Steve Ellcey wrote:
> Re-ping. I know there are discussions about bigger changes to fix the
> various failures listed in PR rtl-optimization/87763 but this patch
> at least fixes one of them (gcc.target/aarch64/lsl_asr_sbfiz.c).
>
> Steve Ellcey
> sell...@marvell.com
So
On Fri, 26 Apr 2019, Martin Liška wrote:
> The patch clarifies that gcc-patches mailing list allows up to 400kB
> size of an email.
Thanks, yes.
As one minor detail, note we have KB in one place and with the
patch would have kB. Technically it's probably KiB, but that
may confuse people more
On 26/04/19 14:36 +0100, Jonathan Wakely wrote:
On 26/04/19 14:30 +0200, Jakub Jelinek wrote:
On Fri, Apr 26, 2019 at 01:25:37PM +0100, Jonathan Wakely wrote:
On 26/04/19 12:48 +0200, Jakub Jelinek wrote:
Hi!
The following patch updates the baseline symbols files from April 18th
Fedora rpm
On 26/04/19 14:30 +0200, Jakub Jelinek wrote:
On Fri, Apr 26, 2019 at 01:25:37PM +0100, Jonathan Wakely wrote:
On 26/04/19 12:48 +0200, Jakub Jelinek wrote:
> Hi!
>
> The following patch updates the baseline symbols files from April 18th
> Fedora rpm build. I've verified the only added lines
Alejandro Martinez Vicente writes:
> Hi,
>
> This patch does two things. For the general vectorizer, it adds support to
> perform fully masked reductions over expressions that don't support masking.
> This is achieved by using VEC_COND_EXPR where possible. At the moment this is
> implemented for
On Wed, Apr 10, 2019 at 10:12 AM Martin Liška wrote:
>
> On 4/9/19 3:19 PM, Jan Hubicka wrote:
> >> Hi.
> >>
> >> There's updated version that supports profile quality for both counts
> >> and probabilities. I'm wondering whether ENTRY and EXIT BBs needs to
> >> have set probability. Apparently,
On 25/04/19 23:43 +0100, Jonathan Wakely wrote:
PR libstdc++/90239
* doc/xml/manual/status_cxx2020.xml: Amend P0591R4 status.
* include/std/scoped_allocator [__cplusplus > 201703L]
(scoped_allocator_adaptor::construct): Define in terms of
Alejandro Martinez Vicente writes:
> Hi,
>
> Current vectorizer doesn't support masked loads for SLP. We should add that,
> to
> allow things like:
>
> void
> f (int *restrict x, int *restrict y, int *restrict z, int n)
> {
> for (int i = 0; i < n; i += 2)
> {
> x[i] = y[i] ? z[i] :
On Thu, Mar 14, 2019 at 3:00 PM marxin wrote:
>
I think it's a good start. Some minor nits:
+/* Dump the visibility of the symbol. */
+
+const char *
+symtab_node::dump_visibility () const
+{
+ static const char * const visibility_types[]
+= { "default", "protected", "hidden", "internal"
On Thu, Mar 14, 2019 at 3:01 PM marxin wrote:
>
>
> gcc/lto/ChangeLog:
OK.
Thanks,
Richard.
> 2019-03-14 Martin Liska
> Hrishikesh Kulkarni
>
> * Make-lang.in: Add lto-common.o.
> * config-lang.in: Likewise for gtfiles.
> * lto-common.c: New file.
>
On Fri, Apr 26, 2019 at 01:25:37PM +0100, Jonathan Wakely wrote:
> On 26/04/19 12:48 +0200, Jakub Jelinek wrote:
> > Hi!
> >
> > The following patch updates the baseline symbols files from April 18th
> > Fedora rpm build. I've verified the only added lines are for the
> > GLIBCXX_3.4.26 or
On Thu, Jan 10, 2019 at 2:55 AM David Malcolm wrote:
>
> PR tree-optimization/88763 reports difficulties in getting useful
> information from the log of tree-ssa-loop-unswitch.c.
>
> As work towards improving this, this patch eliminates all uses of
> dump_file from that source file, in favor of
On 26/04/19 12:48 +0200, Jakub Jelinek wrote:
Hi!
The following patch updates the baseline symbols files from April 18th
Fedora rpm build. I've verified the only added lines are for the
GLIBCXX_3.4.26 or CXXABI_1.3.12 symvers and I don't see any new long double
symbol on powerpc64 or s390x,
Africa Oil & Gas Industry: An Africa Business Community
Hi,
Short term business collaboration. Let me know if you have some time to connect
for more details. Contact email: kamhe...@gmail.com.
Skype: live:kamhed44.
Regards,
Kamran Hedayat.
Click the link below to Join:
On Fri, Apr 26, 2019 at 11:26 AM Martin Liška wrote:
>
> Hi.
>
> We do have vec<...>::is_empty function, but not for hash_{table,map,set}.
> Would you mind adding the function and using it? If so, I can prepare
> a complete patch that will replace all usages of 'elements () > 0',
> '!elements
On 26/04/19 13:57 +0200, Jakub Jelinek wrote:
On Fri, Apr 26, 2019 at 12:10:41PM +0100, Jonathan Wakely wrote:
On 26/04/19 12:48 +0200, Jakub Jelinek wrote:
> Hi!
>
> The following patch updates the baseline symbols files from April 18th
> Fedora rpm build. I've verified the only added lines
On Fri, Apr 26, 2019 at 12:11:55PM +0100, Jonathan Wakely wrote:
> On 26/04/19 09:58 +0200, Rainer Orth wrote:
> > It recently occured to me that almost none of the libstdc++ abi
> > baselines have been updated for the GCC 9 release. The following patch
> > corrects this for Solaris. The
On 26/04/19 09:58 +0200, Rainer Orth wrote:
It recently occured to me that almost none of the libstdc++ abi
baselines have been updated for the GCC 9 release. The following patch
corrects this for Solaris. The baselines were generated on the affected
releases with make new-abi-baseline. Given
On 26/04/19 12:48 +0200, Jakub Jelinek wrote:
Hi!
The following patch updates the baseline symbols files from April 18th
Fedora rpm build. I've verified the only added lines are for the
GLIBCXX_3.4.26 or CXXABI_1.3.12 symvers and I don't see any new long double
symbol on powerpc64 or s390x,
Hi.
The fix is about forgotten target options for which get_valid_option_values
returns empty list.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed to trunk and later than to gcc-9 branch?
Thanks,
Martin
gcc/ChangeLog:
2019-04-26 Martin Liska
Hi!
The following patch updates the baseline symbols files from April 18th
Fedora rpm build. I've verified the only added lines are for the
GLIBCXX_3.4.26 or CXXABI_1.3.12 symvers and I don't see any new long double
symbol on powerpc64 or s390x, except I had to manually remove
Hi.
We do have vec<...>::is_empty function, but not for hash_{table,map,set}.
Would you mind adding the function and using it? If so, I can prepare
a complete patch that will replace all usages of 'elements () > 0', '!elements
()', ...
Martin
>From 5483c1390871733c944470db063e3f9651d4c020 Mon
Ping?
Best regards,
Mihail
On 12/18/2018 12:53 PM, Mihail Ionescu wrote:
On 12/18/2018 09:32 AM, Mihail Ionescu wrote:
Hi All,
In Thumb mode when the function prologue gets expanded, in case of a
multiple register push, additional mov instructions are generated to
save the high
On 4/26/19 10:43 AM, Alexander Monakov wrote:
> On Fri, 26 Apr 2019, Martin Liška wrote:
>
>> I'm suggesting to adjust that to:
>> - -Os will keep using rep-scasb as -Os means optimize for size
>> no matter what speed impact is
>
> I'm not sure it's a good choice, the inline sequence is
>
>
Hi.
The patch clarifies that gcc-patches mailing list allows up to 400kB
size of an email.
Ready to be installed?
Martin
---
htdocs/lists.html | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/htdocs/lists.html b/htdocs/lists.html
index 69fcda4..b566ae0 100644
---
On Fri, 26 Apr 2019, Martin Liška wrote:
> I'm suggesting to adjust that to:
> - -Os will keep using rep-scasb as -Os means optimize for size
> no matter what speed impact is
I'm not sure it's a good choice, the inline sequence is
xorl%eax, %eax
orq $-1, %rcx
Hi.
As mentioned in the PR, strlen expansion leading to rep-scasb leads
to a slow code. The expansion happens for -Os and -O1, with -O2 we
expand into 4B loop if pointer alignment is known to be at least 4.
When using -minline-all-stringops and -O2, the 4B loop happens also
for an unknown
On Fri, Apr 26, 2019 at 08:58:18AM +0200, Richard Biener wrote:
> On Thu, Apr 25, 2019 at 7:52 PM James Clarke wrote:
> >
> > By using ASM_OUTPUT_LABEL, r257511 forced the assembler to start a new
> > bundle when emitting an inline entry label on. Instead, use
> > ASM_OUTPUT_DEBUG_LABEL like for
It recently occured to me that almost none of the libstdc++ abi
baselines have been updated for the GCC 9 release. The following patch
corrects this for Solaris. The baselines were generated on the affected
releases with make new-abi-baseline. Given that they only contain
additions for versions
On Fri, 26 Apr 2019, Kewen.Lin wrote:
> Hi Segher,
>
> Thanks a lot for your comments!
>
> on 2019/4/25 下午8:16, Segher Boessenkool wrote:
>
> > Does it create worse code now? What we have before your patch isn't
> > so super either (it has an sldi in the loop, it has two mtctr too).
> >
On Thu, Apr 25, 2019 at 11:31 PM Jonathan Wakely wrote:
>
> PR libstdc++/90239
> * doc/xml/manual/status_cxx2020.xml: Correct status of P0591R4.
> * doc/html/*: Regenerate.
>
> This corrects the docs to reflect the real status in gcc-9-branch.
> I'll fix it properly on
On Thu, Apr 25, 2019 at 7:52 PM James Clarke wrote:
>
> By using ASM_OUTPUT_LABEL, r257511 forced the assembler to start a new
> bundle when emitting an inline entry label on. Instead, use
> ASM_OUTPUT_DEBUG_LABEL like for the block begin and end labels so tags are
> emitted rather than labels.
Hi Segher,
Thanks a lot for your comments!
on 2019/4/25 下午8:16, Segher Boessenkool wrote:
> Does it create worse code now? What we have before your patch isn't
> so super either (it has an sldi in the loop, it has two mtctr too).
> Maybe you can show the generated code?
It's a good question!
83 matches
Mail list logo
