On 4/29/19 11:27 PM, Eric Gallager wrote:
> On 4/29/19, Eric Gallager wrote:
>> On 4/29/19, Martin Liška wrote:
>>> On 4/26/19 10:31 PM, Bernhard Reutner-Fischer wrote:
On 26 April 2019 16:08:19 CEST, Gerald Pfeifer
wrote:
> On Fri, 26 Apr 2019, Martin Liška wrote:
>> The patch
Hi Jakub!
On Mon, 29 Apr 2019 12:59:03 +0200, Jakub Jelinek wrote:
> On Mon, Apr 29, 2019 at 12:18:15PM +0200, Thomas Schwinge wrote:
> > I know it's very late in the GCC 9 release process, but I'm still
> > catching up with OpenACC patch review, and just at the end of last week
> > I'd noticed t
On Fri, Apr 26, 2019 at 01:57:06PM +0200, Jakub Jelinek wrote:
> And here for powerpc 32-bit and s390 32-bit from binaries provided by
> richi, the former cross-checked from binaries on a recent compile farm
> bootstrap I've done.
And here is riscv64, cross checked between Debian riscv64 build fro
On 30/04/19 10:28 +0200, Jakub Jelinek wrote:
On Fri, Apr 26, 2019 at 01:57:06PM +0200, Jakub Jelinek wrote:
And here for powerpc 32-bit and s390 32-bit from binaries provided by
richi, the former cross-checked from binaries on a recent compile farm
bootstrap I've done.
And here is riscv64, cr
On Tue, Apr 30, 2019 at 09:36:31AM +0100, Jonathan Wakely wrote:
> On 30/04/19 10:28 +0200, Jakub Jelinek wrote:
> > On Fri, Apr 26, 2019 at 01:57:06PM +0200, Jakub Jelinek wrote:
> > > And here for powerpc 32-bit and s390 32-bit from binaries provided by
> > > richi, the former cross-checked from
On 30/04/19 10:54 +0200, Jakub Jelinek wrote:
On Tue, Apr 30, 2019 at 09:36:31AM +0100, Jonathan Wakely wrote:
On 30/04/19 10:28 +0200, Jakub Jelinek wrote:
> On Fri, Apr 26, 2019 at 01:57:06PM +0200, Jakub Jelinek wrote:
> > And here for powerpc 32-bit and s390 32-bit from binaries provided by
On Sun, Feb 24, 2019 at 03:12:38PM +0100, Richard Biener wrote:
> On February 24, 2019 12:58:05 PM GMT+01:00, Jakub Jelinek
> wrote:
> >Hi!
> >
> >These builtins are perfect candidates for bitwise ccp, the bytes are
> >preserved, just byte-swapped.
> >
> >Noticed this while wondering why we haven
On 29/04/2019 17:56, Srinath Parvathaneni wrote:
> Hi All,
>
> This patch is to fix the ICE caused in expand pattern of copysignf
> builtin. This is a back port to r267019 of trunk.
>
> Bootstrapped on aarch64-none-linux-gnu and regression tested on
> aarch64-none-elf.
>
> Ok for gcc 8 branch?
On 29/04/2019 17:58, Srinath Parvathaneni wrote:
> Hi All,
>
> This patch is to fix the ICE caused by expand pattern of copysignf
> builtin. This is a back port to r267019 of trunk.
>
> Bootstrapped on aarch64-none-linux-gnu and regression tested on
> aarch64-none-elf.
>
> Ok for gcc 7 branch?
On 09/04/2019 10:50, Ramana Radhakrishnan wrote:
> This keeps coming up repeatedly and the ACLE has finally added
> __ARM_FEATURE_ATOMICS for the LSE feature in GCC. This is now part of
> the latest ACLE release
> (https://developer.arm.com/docs/101028/latest/5-feature-test-macros)
>
> I know it's
On 16/04/2019 19:32, Jakub Jelinek wrote:
> On Tue, Apr 16, 2019 at 07:50:35PM +0200, Jakub Jelinek wrote:
>> On Fri, Apr 12, 2019 at 05:10:48PM +0100, Ramana Radhakrishnan wrote:
>>> No, that's not right. we should get rid of this.
>>
>> Here is a patch for that.
>>
>> Bootstrapped/regtested on ar
On Tue, Apr 30, 2019 at 10:04:33AM +0100, Jonathan Wakely wrote:
> > Answer for that is easy, because gnu.ver doesn't say so:
>
> Doh, of course.
>
> >
> > _ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE2EEC1Ev;
> >
> > _ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gn
The root_path.cc test had some debugging macros left in accidentally, so
didn't FAIL correctly if an assertion failed.
The string-char8_t.cc tests didn't compile on Windows.
* testsuite/27_io/filesystem/path/decompose/root_path.cc: Remove
macros accidentally left in.
* te
On 30/04/19 12:29 +0200, Jakub Jelinek wrote:
On Tue, Apr 30, 2019 at 10:04:33AM +0100, Jonathan Wakely wrote:
> Answer for that is easy, because gnu.ver doesn't say so:
Doh, of course.
>
_ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE2EEC1Ev;
>
_ZNSt12__shared_ptr
> > > This code was added in 1997 (r14770). In 2004 the documentation was
> > > changed to clarify how things really work (r88999):
> > >
> > > "Note that even a volatile @code{asm} instruction can be moved relative to
> > > other code, including across jump instructions."
> > >
> > > (followed by
On Tue, Apr 30, 2019 at 12:02:18PM +0100, Jonathan Wakely wrote:
> > So, that indeed fails with -O0 -std=c++17 -Wl,--no-demangle
> > https://paste.fedoraproject.org/paste/wvIxqaH37DYNn4b4Cfua~w
> >
> > Unfortunately, at least judging from the libstdc++*debug symbols on riscv64
> > I've posted, it
On 30/04/19 13:35 +0200, Jakub Jelinek wrote:
On Tue, Apr 30, 2019 at 12:02:18PM +0100, Jonathan Wakely wrote:
> So, that indeed fails with -O0 -std=c++17 -Wl,--no-demangle
> https://paste.fedoraproject.org/paste/wvIxqaH37DYNn4b4Cfua~w
>
> Unfortunately, at least judging from the libstdc++*debug
On Tue, Apr 30, 2019 at 10:50:46AM +0100, Richard Earnshaw (lists) wrote:
> > * config/aarch64/aarch64-c.c (aarch64_update_cpp_builtins): Define
> > __ARM_FEATURE_ATOMICS
> >
> > atomics.txt
> >
> > diff --git a/gcc/config/aarch64/aarch64-c.c b/gcc/config/aarch64/aarch64-c.c
> > index fcb1e80177d
On 4/25/19 7:29 PM, Roland Illig wrote:
> There's a linter in contrib/check-internal-format-escaping.py that
> checks whether the base file for translations (such as French or German)
> conform to some basic style rules. This mostly affects the diagnostics
> emitted by GCC.
>
> As the German trans
On Tue, Apr 30, 2019 at 12:38 PM Jakub Jelinek wrote:
>
> On Tue, Apr 30, 2019 at 10:50:46AM +0100, Richard Earnshaw (lists) wrote:
> > > * config/aarch64/aarch64-c.c (aarch64_update_cpp_builtins): Define
> > > __ARM_FEATURE_ATOMICS
> > >
> > > atomics.txt
> > >
> > > diff --git a/gcc/config/aarch
Hello
Two weeks ago I posted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90113 We have some
unnecessary torture runs for gfortran.dg tests. Full description
inside PR.
Regtested r270624 trunk on x86_64:
Unpatched:
=== gfortran tests ===
Running target unix
===
PING^2
On 3/6/19 11:05 AM, Martin Liška wrote:
> @Honza: PING^1
>
> On 2/20/19 10:10 AM, Martin Liška wrote:
>> On 2/19/19 2:25 PM, Martin Jambor wrote:
>>> Hi,
>>>
>>> On Tue, Feb 19 2019, Martin Liška wrote:
On 2/14/19 11:19 AM, Jan Hubicka wrote:
>
>>>
>>> ...
>>>
> Next stage1 we
Hi.
One obvious documentation fix that I'm going to install.
Martin
gcc/ChangeLog:
2019-04-30 Martin Liska
PR debug/90288
* doc/invoke.texi: Add missing dash for gas-locview-support
and gno-as-locview-support.
---
gcc/doc/invoke.texi | 4 ++--
1 file changed, 2 inse
On Tue, 30 Apr 2019 06:48:01 +0900,
Jeff Law wrote:
>
> On 3/26/19 8:21 AM, Yoshinori Sato wrote:
> > I ported linux kernel to Renesas RX.
> >
> > rx-*-elf target output a binary different from the standard ELF.
> > It has the same format as the Renesas compiler.
> >
> > But the linux kernel req
On 4/29/19 9:58 PM, Prathamesh Kulkarni wrote:
> On Tue, 30 Apr 2019 at 02:56, Jeff Law wrote:
>>
>> On 1/30/19 7:10 AM, Bárbara de Castro Fernandes wrote:
>>> This patch simplifies the function tanh (x) * cosh (x) -> sinh (x).
>>> This rule is derived from the relationship between hyperbolic
>>>
On Tue, Apr 30, 2019 at 07:57:20AM -0600, Jeff Law wrote:
> > Just curious, do we want to add math identities like above to match.pd ?
> I'd think so.
>
>
> > In practice, I am not sure how often we'd see "tanh * cosh" instead
> > of sinh directly in source,
> We're often surprised when what ult
On 4/30/19 8:00 AM, Jakub Jelinek wrote:
> On Tue, Apr 30, 2019 at 07:57:20AM -0600, Jeff Law wrote:
>>> Just curious, do we want to add math identities like above to match.pd ?
>> I'd think so.
>>
>>
>>> In practice, I am not sure how often we'd see "tanh * cosh" instead
>>> of sinh directly in s
On 1/10/19 5:14 PM, Ben L wrote:
> Hi all,
>
> First time emailing gcc-patches, so I'm sorry if I get any of this wrong or if
> there's obvious errors repeated in my patches. AFAICT I should be sending each
> change individually rather than as one bulk patch, so I'm sorry about the spam
> too.
>
On 1/10/19 5:15 PM, Ben L wrote:
> Hi all,
>
> First time emailing gcc-patches, so I'm sorry if I get any of this wrong or if
> there's obvious errors repeated in my patches. AFAICT I should be sending each
> change individually rather than as one bulk patch, so I'm sorry about the spam
> too.
>
On 1/10/19 5:17 PM, Ben L wrote:
> Hi all,
>
> First time emailing gcc-patches, so I'm sorry if I get any of this wrong or if
> there's obvious errors repeated in my patches. AFAICT I should be sending each
> change individually rather than as one bulk patch, so I'm sorry about the spam
> too.
>
On 1/10/19 5:17 PM, Ben L wrote:
> Hi all,
>
> First time emailing gcc-patches, so I'm sorry if I get any of this wrong or if
> there's obvious errors repeated in my patches. AFAICT I should be sending each
> change individually rather than as one bulk patch, so I'm sorry about the spam
> too.
>
On 1/10/19 5:18 PM, Ben L wrote:
> Hi all,
>
> First time emailing gcc-patches, so I'm sorry if I get any of this wrong or if
> there's obvious errors repeated in my patches. AFAICT I should be sending each
> change individually rather than as one bulk patch, so I'm sorry about the spam
> too.
>
On 1/10/19 5:18 PM, Ben L wrote:
> Hi all,
>
> First time emailing gcc-patches, so I'm sorry if I get any of this wrong or if
> there's obvious errors repeated in my patches. AFAICT I should be sending each
> change individually rather than as one bulk patch, so I'm sorry about the spam
> too.
>
On 1/10/19 5:19 PM, Ben L wrote:
> Hi all,
>
> First time emailing gcc-patches, so I'm sorry if I get any of this wrong or if
> there's obvious errors repeated in my patches. AFAICT I should be sending each
> change individually rather than as one bulk patch, so I'm sorry about the spam
> too.
>
On 1/10/19 5:16 PM, Ben L wrote:
> Hi all,
>
> First time emailing gcc-patches, so I'm sorry if I get any of this wrong or if
> there's obvious errors repeated in my patches. AFAICT I should be sending each
> change individually rather than as one bulk patch, so I'm sorry about the spam
> too.
>
On 2/16/19 12:12 AM, Jakub Jelinek wrote:
> Hi!
>
> Both the C and C++ standard guarantee that the argc argument to main is
> non-negative, the following patch sets (or adjusts) the corresponding
> SSA_NAME_RANGE_INFO. While main is just one, with IPA VRP it can also
> propagate etc. I had to ch
Fix several bugs in the encoding conversions for filesystem::path that
prevent conversion of Unicode characters outside the Basic Multilingual
Plane, and prevent returning basic_string specializations with
alternative allocator types.
The std::codecvt_utf8 class template is not suitable for UTF-1
On 4/29/19 3:41 PM, Giuliano Augusto Faulin Belinassi wrote:
> Hi.
> Ping :-)
> (I hope I am not bothering you with it)
> Giuliano.
>
> On Thu, Jan 10, 2019 at 6:51 PM Giuliano Belinassi
> wrote:
>>
>> Previously, the tests 'sinhatanh-2.c' and 'sinhatanh-3.c' did not count
>> the number of functi
On Tue, Apr 30, 2019 at 09:03:07AM -0600, Jeff Law wrote:
> On 2/16/19 12:12 AM, Jakub Jelinek wrote:
> > Both the C and C++ standard guarantee that the argc argument to main is
> > non-negative, the following patch sets (or adjusts) the corresponding
> > SSA_NAME_RANGE_INFO. While main is just on
On 4/29/19 10:28 AM, Roman Zhuykov wrote:
> Hi, Segher
>
> In pr84524.c we got a loop with an extended inline asm:
> asm volatile ("" : "+r" (v))
> which also gives us a “surprising” situation Alexander predicts.
>
> For sched-deps scanner such volatile asm is a “true barrier”
On 4/23/19 4:06 AM, Martin Liška wrote:
> On 4/19/19 2:28 AM, Martin Sebor wrote:
>> On 4/18/19 5:09 AM, Martin Liška wrote:
>>> Hi.
>>>
>>> The patch distinguishes among target and target_clone attribute when
>>> reporting for an error. I've also reworded the affected error messages
>>> a bit.
>>>
On 4/5/19 4:42 AM, Martin Liška wrote:
> Hi.
>
> The patch adds a new config that makes LTO+PGO bootstrap faster by
> using LTO only in stage4. In stage3, generators are build with LTO
> in order to collect a reasonable profile for LTO FE.
>
> Ready for trunk?
> Thanks,
> Martin
>
> ChangeLog:
>
On 4/30/19 7:55 AM, Yoshinori Sato wrote:
> On Tue, 30 Apr 2019 06:48:01 +0900,
> Jeff Law wrote:
>>
>> On 3/26/19 8:21 AM, Yoshinori Sato wrote:
>>> I ported linux kernel to Renesas RX.
>>>
>>> rx-*-elf target output a binary different from the standard ELF.
>>> It has the same format as the Renes
On 3/14/19 10:46 PM, JiangNing OS wrote:
> This patch is to fix a missing ifcvt opportunity in back-end. For the simple
> case below,
>
> if (...)
> x = a; /* x is memory */
> /* no else */
>
> We can generate conditional move and remove the branch as below if the target
> cost is acceptab
On 4/29/19 4:47 AM, Martin Liška wrote:
> On 4/26/19 11:05 AM, Martin Liška wrote:
>> Then I'm very open to adjust that even for -Os to 'call strlen'.
> That said, I'm suggesting following updated patch.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Thanks,
> Mart
In combination with a related recently committed patch
(https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00989.html), the attached patch
resolves the issues described in this problem report. This patch also includes
tests to exercise the previously committed patch.
This patch includes redundant
On 4/25/19 11:29 AM, Roland Illig wrote:
> There's a linter in contrib/check-internal-format-escaping.py that
> checks whether the base file for translations (such as French or German)
> conform to some basic style rules. This mostly affects the diagnostics
> emitted by GCC.
>
> As the German tran
On 4/1/19 6:11 AM, Martin Liška wrote:
> Hi.
>
> Last week I was curious which warnings are disabled by default on top
> of -Wall and -Wextra. Thus I used --help=warning and noticed some discrepancy
> in between documentation and output of the --help option.
>
> I created PR89885 where I explaine
On 1/22/19 10:55 AM, David Malcolm wrote:
> PR driver/88911 reports an issue where the user couldn't remember the spelling
> of the "-dumpspecs" option, and attempted various similar spellings, but many
> of them failed to contain a suggestion of the correct spelling:
>
> $ gcc q.c -dump-spec
>
On Tue, Apr 30, 2019 at 11:04:10AM -0500, Kelvin Nilsen wrote:
>
> In combination with a related recently committed patch
> (https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00989.html), the attached
> patch resolves the issues described in this problem report. This patch also
> includes tests to
Hi,
this patch adds some notes on LTO/IPA changes and some statistics
on bulid-time/memory use improvements I collected this weekend.
I also added some of FDO changes I rememebr. Martin, perhaps you can
do more.
Honza
Index: changes.html
==
On 2/10/19 6:09 PM, Hans-Peter Nilsson wrote:
> Here's the follow-up, getting rid of the observed
> alignment-padding in execute/930126-1.c: the x parameter in f
> spuriously being runtime-aligned to BITS_PER_WORD. I separated
> this change because this is an older issue, a change introduced
> in
On Mon, Apr 29, 2019 at 06:29:50PM +, Iain Sandoe wrote:
>
> > On 26 Apr 2019, at 15:08, 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.
>
> > As one minor detail, note we
On Tue, Apr 30, 2019 at 1:29 AM Jakub Jelinek wrote:
> From what I can see in riscv/sync.md, there is 32 bit and 64 bit compare and
> swap, but not 16 bit (no idea why it doesn't emulate 8 bit and 16 bit
> cas using 32 bit one).
This is a known problem on our to do list, and there is already a
bu
On Tue, Apr 30, 2019 at 12:02:04PM -0700, Jim Wilson wrote:
> On Tue, Apr 30, 2019 at 1:29 AM Jakub Jelinek wrote:
> > From what I can see in riscv/sync.md, there is 32 bit and 64 bit compare and
> > swap, but not 16 bit (no idea why it doesn't emulate 8 bit and 16 bit
> > cas using 32 bit one).
>
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the German team of translators. The file is available at:
https://translationproject.org/latest/gcc/de.po
(This file, 'gcc-9.1-b20190414.de.po',
On 30/04/19 21:06 +0200, Jakub Jelinek wrote:
On Tue, Apr 30, 2019 at 12:02:04PM -0700, Jim Wilson wrote:
On Tue, Apr 30, 2019 at 1:29 AM Jakub Jelinek wrote:
> From what I can see in riscv/sync.md, there is 32 bit and 64 bit compare and
> swap, but not 16 bit (no idea why it doesn't emulate 8
On 3/27/19 1:43 AM, marxin wrote:
>
> gcc/ChangeLog:
>
> 2019-03-27 Martin Liska
>
> * dbgcnt.c (dbg_cnt_process_single_pair): Fix GNU coding style.
> (dbg_cnt_process_opt): Parse first tokens aas
> dbg_cnt_process_single_pair is also using strtok.
> ---
> gcc/dbgcnt.c | 25
On 3/27/19 2:38 AM, marxin wrote:
> gcc/ChangeLog:
>
> 2019-03-27 Martin Liska
>
> * dbgcnt.c (dbg_cnt_set_limit_by_name): Add new argument
> aux_base and filter based on aux_base_name.
> (dbg_cnt_process_single_pair): Parse aux_base.
> * doc/invoke.texi: Document new e
On 3/27/19 2:39 AM, marxin wrote:
>
> gcc/ChangeLog:
>
> 2019-03-27 Martin Liska
>
> * dbgcnt.c (print_limit_reach): New function.
> (dbg_cnt): Use it.
> ---
> gcc/dbgcnt.c | 26 --
> 1 file changed, 16 insertions(+), 10 deletions(-)
>
Given this is dbgcn
I discovered we were not correctly marking the TS array for
language-specific _EXPR nodes. We got away with this because the GC
marking used other means for dealing with such nodes. I, however, was
relying on it for modules streaming.
applying to trunk.
nathan
--
Nathan Sidwell
2019-04-30
Hi!
I've backported following 46 patches from trunk to gcc-8-branch,
bootstrapped/regtested on x86_64-linux and i686-linux and committed.
Jakub
2019-04-30 Jakub Jelinek
Backported from mainline
2019-02-20 Jakub Jelinek
PR middle-end/88074
PR middle-
On Tue, Apr 30, 2019 at 12:06 PM Jakub Jelinek wrote:
> I think you can e.g. have a look at what alpha does in
> alpha_split_compare_and_swap_12, it doesn't have a hw 8-bit or 16-bit
> compare and swap either.
Thanks. I had noticed that the rs6000 port had what I needed, but
looking the alpha on
The SiFive 7 series cores have macro fusion support to convert a branch over
a single instruction into a conditionally executed instruction. This adds
a conditional move pattern, enabled only for the SiFive 7 series cores, that
implements the initial optimization support for this feature. This gi
The current generic implementation of __complex_proj used when cproj is
not available calculates the wrong projection, giving a different result
than given by C99's cproj.
When C99 cproj is not available but isinf and copysign are, use those to
give correct results for float, double and long doub
On Tue, Apr 30, 2019 at 4:47 PM Jim Wilson wrote:
> The SiFive 7 series cores have macro fusion support to convert a branch over
> a single instruction into a conditionally executed instruction. This adds
> a conditional move pattern, enabled only for the SiFive 7 series cores, that
> implements
66 matches
Mail list logo
