Segher Boessenkool writes:
> Hi!
>
> On Thu, Mar 05, 2020 at 10:46:58AM +0800, Jiufu Guo wrote:
>> PR93709 mentioned regressions on maxlocval_4.f90 and minlocval_f.f90 which
>> relates to max of '-inf' and 'nan'. This regression occur on P9 which has
>> new instruction 'xsmaxcdp/xsmincdp'.
>>
Hi,
On 2020/3/9 下午10:32, Segher Boessenkool wrote:
Hi!
On Mon, Mar 09, 2020 at 01:58:01PM +0800, binbin wrote:
2020-03-09 Bin Bin Lv
* config/rs6000/rs6000-internal.h (altivec_builtin_mask_for_load,
builtin_mode_to_type[MAX_MACHINE_MODE][2]): Remove the declaration.
Just
On 2020/3/10 05:28, Segher Boessenkool wrote:
On Thu, Mar 05, 2020 at 02:21:58AM -0600, luo...@linux.ibm.com wrote:
From: Xionghu Luo
Backport the patch to fix failures on P9 and P8BE, P7LE for PR94036.
No changes were needed?
Yes, no conflicts of the patch and instruction counts are
On 2020-03-10 01:25, Segher Boessenkool wrote:
> On Mon, Mar 09, 2020 at 07:42:20PM +0100, J.W. Jagersma wrote:
>> On 2020-03-09 19:01, Segher Boessenkool wrote:
>>> On Mon, Mar 09, 2020 at 01:54:53PM +0100, Richard Biener wrote:
int foo = 0
try
{
On 2020-03-09 23:10, Segher Boessenkool wrote:
> Hi!
>
> On Sun, Mar 08, 2020 at 05:18:21PM +0100, J.W. Jagersma wrote:
>> There is also still the question of whether non-volatile asms should be
>> allowed to throw or not. I don't know if that should be discussed here
>> or on the PR.
>
> I
On Mon, 9 Mar 2020, Christophe Lyon wrote:
> Hi Joseph,
>
> I've noticed that your patch introduces regressions on aarch64:
> FAIL: gcc.target/aarch64/sve/acle/general-c/sizeless-1.c
> -march=armv8.2-a+sve (test for errors, line 33)
> we now get
>
On Mon, Mar 09, 2020 at 07:42:20PM +0100, J.W. Jagersma wrote:
> On 2020-03-09 19:01, Segher Boessenkool wrote:
> > On Mon, Mar 09, 2020 at 01:54:53PM +0100, Richard Biener wrote:
> >> int foo = 0
> >> try
> >> {
> >> asm volatile ("..." : "=r" (foo));
> >>
On 3/9/20 5:39 PM, Martin Sebor wrote:
On 3/9/20 1:40 PM, Jason Merrill wrote:
On 3/9/20 12:31 PM, Martin Sebor wrote:
On 2/28/20 1:24 PM, Jason Merrill wrote:
On 2/28/20 12:45 PM, Martin Sebor wrote:
On 2/28/20 9:58 AM, Jason Merrill wrote:
On 2/24/20 6:58 PM, Martin Sebor wrote:
On 3/9/20 7:32 PM, Marek Polacek wrote:
On Mon, Mar 02, 2020 at 05:50:01PM -0500, Jason Merrill wrote:
On 2/29/20 2:32 PM, Marek Polacek wrote:
The point of this patch is to fix the recurring problem of trees
generated by convert_like while processing a template that break when
substituting.
On Mon, Mar 02, 2020 at 05:50:01PM -0500, Jason Merrill wrote:
> On 2/29/20 2:32 PM, Marek Polacek wrote:
> > The point of this patch is to fix the recurring problem of trees
> > generated by convert_like while processing a template that break when
> > substituting. For instance, when
The filesystem::path::operator+= and filesystem::path::concat functions
operate directly on the native format of the path and so can cause a
path to mutate to a completely different type.
For Windows combining a filename "x" with a filename ":" produces a
root-name "x:". Similarly, a Cygwin
This patch adds a new flag -fconcepts-diagnostics-depth to the C++ frontend
which controls how deeply we replay errors when diagnosing a constraint
satisfaction failure. The default is -fconcepts-diagnostics-depth=1 which
diagnoses only the topmost constraint satisfaction failure and is
The first patch tries to avoid changing our current default diagnostics. But
for the sake of consistency we arguably should also respect
current_constraint_diagnosis_depth in diagnose_compound_requirement() like we do
in the other error-replaying diagnostic routine. But doing so would be a
Hi all,
second version of the patch for the 200 characters limit for literal
strings addressing comments.
make check-jit is passing clean.
Best Regards
Andrea
gcc/jit/ChangeLog
2020-??-?? Andrea Corallo
* jit-playback.h
(gcc::jit::playback::context m_recording_ctxt):
Hi!
On Sun, Mar 08, 2020 at 05:18:21PM +0100, J.W. Jagersma wrote:
> The only question I have left now is if my proposed change to the
> documentation is acceptable or should be expanded/reworded.
I think it is fine. It's easier to judge if you look fresh at it, in
my experience, so I might
Hi,
Please see attached the patches to add -moutline-atomics to the gcc-9 branch.
Tested on graviton2 aarch64-linux with bootstrap and
`make check` passes with no new fails.
Tested `make check` on glibc built with gcc-9 with and without
"-moutline-atomics"
and CFLAGS=" -O2 -g
On 3/9/20 1:40 PM, Jason Merrill wrote:
On 3/9/20 12:31 PM, Martin Sebor wrote:
On 2/28/20 1:24 PM, Jason Merrill wrote:
On 2/28/20 12:45 PM, Martin Sebor wrote:
On 2/28/20 9:58 AM, Jason Merrill wrote:
On 2/24/20 6:58 PM, Martin Sebor wrote:
-Wredundant-tags doesn't consider type
On Thu, Mar 05, 2020 at 02:21:58AM -0600, luo...@linux.ibm.com wrote:
> From: Xionghu Luo
>
> Backport the patch to fix failures on P9 and P8BE, P7LE for PR94036.
No changes were needed?
> Tested pass on P9/P8/P7, ok to commit?
Yes, okay for 9. Thanks!
Segher
> 2020-03-05 Luo
On 3/6/20 7:57 AM, Jakub Jelinek wrote:
Hi!
Since r10-6527-gaaa26bf496a646778ac861aed124d960b5bf549f fold_for_warn
will perform maybe_constant_value even on some cp_fold produced trees and
so can include rotate exprs which were removed last fall from constexpr.c
OK. It's unfortunate that
On Mon, Mar 09, 2020 at 04:25:00PM -0400, Marek Polacek wrote:
> On Mon, Mar 09, 2020 at 03:37:56PM -0400, Jason Merrill wrote:
> > On 3/9/20 9:40 AM, Marek Polacek wrote:
> > > On Mon, Mar 09, 2020 at 09:19:30AM -0400, Jason Merrill wrote:
> > > > On 3/9/20 8:58 AM, Jakub Jelinek wrote:
> > > > >
On 3/5/20 5:26 PM, Jeff Law wrote:
On Fri, 2020-02-14 at 15:41 -0700, Martin Sebor wrote:
Because attribute weakref introduces a kind of a definition, it can
only be applied to declarations of symbols that are not defined. GCC
normally issues a warning when the attribute is applied to a
On Mon, Mar 09, 2020 at 03:37:56PM -0400, Jason Merrill wrote:
> On 3/9/20 9:40 AM, Marek Polacek wrote:
> > On Mon, Mar 09, 2020 at 09:19:30AM -0400, Jason Merrill wrote:
> > > On 3/9/20 8:58 AM, Jakub Jelinek wrote:
> > > > On Fri, Mar 06, 2020 at 07:43:43PM -0500, Jason Merrill wrote:
> > > > >
Hi!
On Thu, Mar 05, 2020 at 10:46:58AM +0800, Jiufu Guo wrote:
> PR93709 mentioned regressions on maxlocval_4.f90 and minlocval_f.f90 which
> relates to max of '-inf' and 'nan'. This regression occur on P9 which has
> new instruction 'xsmaxcdp/xsmincdp'.
> The similar issue also could be find on
> On Mon, Mar 9, 2020 at 9:56 AM Martin Liška wrote:
> >
> > On 3/9/20 4:36 PM, H.J. Lu wrote:
> > > We nee to support different variables, like TLS, data and bss variables.
> >
> > Why do we need TLS? Right now, it's not supported by nm. Or am I wrong?
>
> Since you are introducing symbol
Hello,
On Mon, 9 Mar 2020, Martin Liška wrote:
> On 3/9/20 4:36 PM, H.J. Lu wrote:
> > We nee to support different variables, like TLS, data and bss variables.
>
> Why do we need TLS? Right now, it's not supported by nm.
Of course it does. It's the 'T' (or 't') character. When you introduce
On 3/9/20 12:31 PM, Martin Sebor wrote:
On 2/28/20 1:24 PM, Jason Merrill wrote:
On 2/28/20 12:45 PM, Martin Sebor wrote:
On 2/28/20 9:58 AM, Jason Merrill wrote:
On 2/24/20 6:58 PM, Martin Sebor wrote:
-Wredundant-tags doesn't consider type declarations that are also
the first uses of the
On 3/9/20 9:40 AM, Marek Polacek wrote:
On Mon, Mar 09, 2020 at 09:19:30AM -0400, Jason Merrill wrote:
On 3/9/20 8:58 AM, Jakub Jelinek wrote:
On Fri, Mar 06, 2020 at 07:43:43PM -0500, Jason Merrill wrote:
On 3/6/20 6:54 PM, Marek Polacek wrote:
I got a report that building Chromium fails
On 2020-03-09 19:01, Segher Boessenkool wrote:
> Hi!
>
> On Mon, Mar 09, 2020 at 01:54:53PM +0100, Richard Biener wrote:
>> I think memory operands are fine - my original concern was about
>> register outputs and SSA form that should reflect the correct def
>> on the EH vs non-EH edge. From a
On Mon, Mar 9, 2020 at 9:56 AM Martin Liška wrote:
>
> On 3/9/20 4:36 PM, H.J. Lu wrote:
> > We nee to support different variables, like TLS, data and bss variables.
>
> Why do we need TLS? Right now, it's not supported by nm. Or am I wrong?
Since you are introducing symbol types, why not
... a call to ranges::begin on an input range.
This implements LWG 3286. The new wording for the single-argument
subrange::subrange constructor is implemented by splitting the constructor into
two delegating constructors, one constrained by _S_store_size and the other by
!_S_store_size.
Tested
Hi!
On Mon, Mar 09, 2020 at 01:54:53PM +0100, Richard Biener wrote:
> I think memory operands are fine - my original concern was about
> register outputs and SSA form that should reflect the correct def
> on the EH vs non-EH edge. From a "miscompile" perspective
> doing nothig which means
Hi,
There is no single PC offset that is correct given CPUs may use different
offsets.
GCC may also schedule the instruction that stores the PC. This feature used to
work on early Arms but is no longer functional or useful today, so the best way
forward is to remove it altogether. There are many
On Mon, Mar 09, 2020 at 09:48:01AM -0500, will schmidt wrote:
> On Tue, 2020-02-25 at 12:15 -0600, will schmidt wrote:
> > PR90763: PowerPC vec_xl_len should take const argument.
>
> ping! :-)
https://gcc.gnu.org/pipermail/gcc-patches/2020-February/540969.html
Segher
On Mon, Mar 9, 2020 at 10:26 AM Wilco Dijkstra wrote:
>
> Hi Christophe,
>
> > I noticed a regression introduced by Delia's patch "aarch64: ACLE
> > intrinsics for BFCVTN, BFCVTN2 and BFCVT":
> > (on aarch64-linux-gnu)
> > FAIL: g++.dg/cpp0x/variadic-sizeof4.C -std=c++14 (internal compiler
Hi Christophe,
> I noticed a regression introduced by Delia's patch "aarch64: ACLE
> intrinsics for BFCVTN, BFCVTN2 and BFCVT":
> (on aarch64-linux-gnu)
> FAIL: g++.dg/cpp0x/variadic-sizeof4.C -std=c++14 (internal compiler error)
>
> I couldn't reproduce it with current ToT, until I realized
On 3/9/20 4:36 PM, H.J. Lu wrote:
We nee to support different variables, like TLS, data and bss variables.
Why do we need TLS? Right now, it's not supported by nm. Or am I wrong?
About BSS and DATA I agree that it would be handy. I can theoretically
covered with code in
From: Andrew Pinski
The problem here is there was a typo in the documentation
for the 'A' modifier in the table, it was recorded as 'a'
in the table on the modifier column.
Committed as obvious.
2020-03-09 Andrew Pinski
PR inline-asm/94095
* doc/extend.texi (x86 Operand
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 Swedish team of translators. The file is available at:
https://translationproject.org/latest/gcc/sv.po
(This file,
On 2/28/20 1:24 PM, Jason Merrill wrote:
On 2/28/20 12:45 PM, Martin Sebor wrote:
On 2/28/20 9:58 AM, Jason Merrill wrote:
On 2/24/20 6:58 PM, Martin Sebor wrote:
-Wredundant-tags doesn't consider type declarations that are also
the first uses of the type, such as in 'void f (struct S);' and
Hi Bin Bin,
On Mon, Mar 09, 2020 at 09:55:22PM +0800, binbin wrote:
> OK, removed the empty line and showed the changelog. And I found that the
> declaration in rs6000-internal.h should also be removed, right? The
> attachment is the latest patch. Thanks.
> gcc/ChangeLog
>
> 2020-03-09 Bin
On Mon, Mar 09, 2020 at 04:24:20PM +0100, Tobias Burnus wrote:
> PS: While amdgcn was added in GCC 9, offloading is
> only supported in GCC 10 – hence, there is no backporting
> needed.
>
> 2020-03-09 Tobias Burnus
>
>* configure.ac: Build libgomp by default for amdgcn.
>*
On 2020-03-09 13:13, Richard Sandiford wrote:
> Thanks for doing this.
Hi Richard, thanks for your response.
> "J.W. Jagersma" writes:
>> On 2020-03-07 20:20, Segher Boessenkool wrote:
>>> Some comments:
>>>
+When non-call exceptions (@option{-fnon-call-exceptions}) are enabled, a
On Fri, 6 Mar 2020 at 16:03, Wilco Dijkstra wrote:
>
> Inline assembler instructions don't have latency info and the scheduler does
> not attempt to schedule them at all - it does not even honor latencies of
> asm source operands. As a result, SIMD intrinsics which are implemented using
> inline
On Mon, Mar 9, 2020 at 2:30 AM Martin Liška wrote:
>
> Hi.
>
> With change of -fno-common default for GCC 10 we're facing serious
> problem with LTO where one can't distinguish in between global symbols
> and variables based on the output of nm:
>
As reported by richi on IRC, libgomp is not build
by default for amdgcn – and as Jakub pointed out,
that's setup in configure{,.ac}.
(It is disabled by default but enabled for POSIX systems,
nvptx
This patch adds it – OK for the trunk?
Tobias
PS: While amdgcn was added in GCC 9, offloading is
My Attachment seems to have been stripped. So sending it again inline and
hoping the tabs don't get stripped.
diff --git a/gcc/config/aarch64/aarch64-simd.md
b/gcc/config/aarch64/aarch64-simd.md
index
89aaf8c018e3340dd2d53fc2a6538d3d1220b103..47428dd3e9c4fa8fc1f3d876e774defb6bc64640
100644
On Fri, 6 Mar 2020 at 00:50, Joseph Myers wrote:
>
> Bug 93577, apparently a regression (although it isn't very clear to me
> exactly when it was introduced; tests I made with various past
> compilers produced inconclusive results, including e.g. ICEs appearing
> with 64-bit-host compilers for
On Tue, 2020-02-25 at 12:15 -0600, will schmidt wrote:
> PR90763: PowerPC vec_xl_len should take const argument.
ping! :-)
thanks
-Will
>
> Hi,
>
> Adds some logic in altivec_resolve_overloaded_builtin() to handle
> the
> scenario where const * arguments are passed in to the
>
Hi!
On Mon, Mar 09, 2020 at 01:58:01PM +0800, binbin wrote:
> 2020-03-09 Bin Bin Lv
>
> * config/rs6000/rs6000-internal.h (altivec_builtin_mask_for_load,
> builtin_mode_to_type[MAX_MACHINE_MODE][2]): Remove the declaration.
Just write "builtin_mode_to_type", nothing []? Writing
On Sat, Mar 7, 2020 at 1:32 PM Steve Kargl
wrote:
>
> Fix the simplification and handling of the degree trigonometric functions.
> This includes fixing a number of ICEs. See PR 93871.
>
> ChangeLog and patch attached.
As the author of the original degree-trig functions I intend to review
this
Hi Sir,
Good day.
Are you looking for
l Pleat soap wrapping machine
l Soap stretch film wapping machine
l Flow type soap wrapping machine
we are one of the largest soap warpping machines manufacturers in China. we
provide with reliable prices and Only High quality , which has good reputation
Hi All,
This works around an ICE in reload where from expand we get the following RTL
generated for VSTRUCT mode writes:
(insn 446 354 445 2 (set (reg:CI 383)
(subreg:CI (reg:V4SI 291) 0)) "small.i":146:22 3408 {*aarch64_movci}
(nil))
This sequence is trying to say two things:
1) liveliness:
Hi Segher,
On 2020/3/6 下午11:25, Segher Boessenkool wrote:
Hi!
On Fri, Mar 06, 2020 at 10:20:08AM +0800, binbin wrote:
OK, changed the code. Bootstrap and regression tests were done on
powerpc64le-linux-gnu (LE) with no regressions. Thanks for your suggestion.
Yes, this is fine, approved
On Mon, Mar 09, 2020 at 09:19:30AM -0400, Jason Merrill wrote:
> On 3/9/20 8:58 AM, Jakub Jelinek wrote:
> > On Fri, Mar 06, 2020 at 07:43:43PM -0500, Jason Merrill wrote:
> > > On 3/6/20 6:54 PM, Marek Polacek wrote:
> > > > I got a report that building Chromium fails with the "modifying a const
On Thu, 5 Mar 2020 at 16:49, Jeff Law wrote:
>
> On Mon, 2020-03-02 at 16:40 +, Richard Earnshaw (lists) wrote:
> > On 02/03/2020 15:46, Jeff Law wrote:
> > > More minor fallout from Vlad's IRA changes.
> > >
> > > Previously this test used r3 to hold a value across a call (it's an ipa-ra
> >
On 3/9/20 8:58 AM, Jakub Jelinek wrote:
On Fri, Mar 06, 2020 at 07:43:43PM -0500, Jason Merrill wrote:
On 3/6/20 6:54 PM, Marek Polacek wrote:
I got a report that building Chromium fails with the "modifying a const
object" error. After some poking I realized it's a bug in GCC, not in
their
On 3/8/20 5:33 PM, Marek Polacek wrote:
On Sun, Mar 08, 2020 at 01:25:17AM -0500, Jason Merrill wrote:
On 3/7/20 6:02 PM, Marek Polacek wrote:
On Sat, Mar 07, 2020 at 01:21:41AM -0500, Jason Merrill wrote:
On 3/6/20 8:12 PM, Marek Polacek wrote:
On Fri, Mar 06, 2020 at 05:49:07PM -0500,
On 3/6/20 6:07 PM, Segher Boessenkool wrote:
On Fri, Mar 06, 2020 at 02:07:15PM +0100, Martin Liška wrote:
After r9-1623-gc518c1025b435e1c593a745036fc9b8ed04c5819 the code was
changed to:
- if (align_jumps_max_skip <= 0)
- align_jumps_max_skip = 15;
- if
On 3/2/20 1:26 PM, Martin Liška wrote:
Hi.
It's a documentation update for the new -fprofile-reproducible option.
Martin
---
htdocs/gcc-10/changes.html | 6 ++
1 file changed, 6 insertions(+)
Installed as 451b55cd9e598edff705b6dd3c4af496472aecef.
Martin
On Fri, Mar 06, 2020 at 07:43:43PM -0500, Jason Merrill wrote:
> On 3/6/20 6:54 PM, Marek Polacek wrote:
> > I got a report that building Chromium fails with the "modifying a const
> > object" error. After some poking I realized it's a bug in GCC, not in
> > their codebase.
> >
> > Much like
On Mon, Mar 9, 2020 at 1:14 PM Richard Sandiford
wrote:
>
> Thanks for doing this.
>
> "J.W. Jagersma" writes:
> > On 2020-03-07 20:20, Segher Boessenkool wrote:
> >> Hi!
> >>
> >> On Sat, Mar 07, 2020 at 06:12:45PM +0100, J.W. Jagersma wrote:
> >>> The following patch extends the generation of
Thanks for doing this.
"J.W. Jagersma" writes:
> On 2020-03-07 20:20, Segher Boessenkool wrote:
>> Hi!
>>
>> On Sat, Mar 07, 2020 at 06:12:45PM +0100, J.W. Jagersma wrote:
>>> The following patch extends the generation of exception handling
>>> information to cover volatile asms too. This was
On Mon, 9 Mar 2020, Jakub Jelinek wrote:
> Hi!
>
> As mentioned in the PR, on a largish C++ testcase the compile time
> on i686-linux is about 16 minutes on a fast box, mostly spent in
> find_base_term recursive calls dealing with very deep chains of preserved
> VALUEs during var-tracking.
>
>
Hi!
As mentioned in the PR, on a largish C++ testcase the compile time
on i686-linux is about 16 minutes on a fast box, mostly spent in
find_base_term recursive calls dealing with very deep chains of preserved
VALUEs during var-tracking.
The following patch punts after we process many VALUEs (we
It looks great I'll keep in mind this tip next time.
Thank you,
Clauidu
From: Gerald Pfeifer
Sent: Saturday, March 7, 2020 11:05 PM
To: Claudiu Zissulescu ; Martin Sebor
Cc: gcc-patches@gcc.gnu.org ; Jeff Law
; Francois Bedard ; Claudiu Zissulescu
;
On Fri, 6 Mar 2020 at 11:46, Kyrill Tkachov wrote:
>
> Hi Delia,
>
> On 3/5/20 4:38 PM, Delia Burduv wrote:
> > Hi,
> >
> > This is the latest version of the patch. I am forcing -mfloat-abi=hard
> > because the code generated is slightly differently depending on the
> > float-abi used.
>
>
>
Hi.
With change of -fno-common default for GCC 10 we're facing serious
problem with LTO where one can't distinguish in between global symbols
and variables based on the output of nm:
https://sourceware.org/bugzilla/show_bug.cgi?id=25355
$ cat nm.c
char nm_test_var;
$ gcc-9 nm.c -c -fno-common
Forwarding to public list.
-- Forwarded message -
From: Bin.Cheng
Date: Mon, Mar 9, 2020 at 5:07 PM
Subject: Re: [PATCH PR93674]Avoid introducing IV of enumeral type in
case of -fstrict-enums
To: Richard Biener
On Tue, Mar 3, 2020 at 5:36 PM Richard Biener
wrote:
>
> On Mon,
gcc/c-family/ChangeLog:
PR pch/86674
* c-pch.c (c_common_valid_pch): Use cpp_warning with CPP_W_INVALID_PCH
reason to fix -Werror=invalid-pch and -Wno-error=invalid-pch switches.
---
gcc/c-family/ChangeLog | 6 ++
gcc/c-family/c-pch.c | 40
On 3/6/20 11:12 AM, Jonathan Wakely wrote:
On 06/03/20 10:09 +, Jonathan Wakely wrote:
On 06/03/20 07:06 +0100, François Dumont wrote:
I started to work on ranges::equal to find out if what I am trying
to do is totally silly.
With this patch ranges::equal is in pare with std::equal
70 matches
Mail list logo
