On 3/16/21 1:16 AM, Ilya Leoshkevich wrote:
> Bootstrapped and regtested on s390x-redhat-linux. Ok for master?
>
>
>
> When a long double is passed to an asm statement with a "+fvm"
> constraint, a LRA loop occurs. This happens, because LRA chooses the
> widest register class in this case (VEC
Bootstrapped and regtested on s390x-redhat-linux. Ok for master?
When a long double is passed to an asm statement with a "+fvm"
constraint, a LRA loop occurs. This happens, because LRA chooses the
widest register class in this case (VEC_REGS), but the code generated
by s390_md_asm_adjust() alw
On Mon, Mar 15, 2021 at 03:28:06PM -0400, Nathan Sidwell wrote:
>
> I'd failed to correctly restrict some checks to lp64 x86 targets.
>
> PR c++/99601
> gcc/testsuite/
> * g++.dg/modules/builtin-3_a.C: Fix lp64 x86 detection.
> * g++.dg/modules/builtin-3_b.C: Fix lp64 x86
This patch updates libgo to the Go 1.16.2 release. Bootstrapped and
ran Go testsuite on x86_64-pc-linux-gnu. Committed to mainline.
Ian
d5eae60451faeea9d87ae3815f7e4db0e6e182ed
diff --git a/gcc/go/gofrontend/MERGE b/gcc/go/gofrontend/MERGE
index e5756c6662c..c0bfa1ff78a 100644
--- a/gcc/go/gofro
On 3/12/21 7:02 AM, Martin Liška wrote:
On 3/12/21 2:56 PM, David Malcolm wrote:
On Fri, 2021-03-12 at 09:45 +0100, Martin Liška wrote:
Identified by my check that compares documentation of params
with content of --help=param output.
Pushed as obvious.
Martin
Thanks.
Which check is this, BT
I'd failed to correctly restrict some checks to lp64 x86 targets.
PR c++/99601
gcc/testsuite/
* g++.dg/modules/builtin-3_a.C: Fix lp64 x86 detection.
* g++.dg/modules/builtin-3_b.C: Fix lp64 x86 detection.
--
Nathan Sidwell
diff --git c/gcc/testsuite/g++.dg/modul
This bug was caused by not marking dependent template aliases
correctly -- these things look like typedefs, but are not
(necessarily) equivalent to the canonical type. We need to record that.
PR c++/99496
gcc/cp/
* module.cc (trees_out::decl_value): Adjust typedef stream
The TYPE_MAIN_VARIANT() here was, for casts to a typedef'd type name,
resulting in all information about the typedef's involvement getting
lost. This drops necessary information for warnings and can make them
confusing or even misleading. It also makes specialized warnings for
unspecified-size s
On Fri, Mar 12, 2021 at 09:35:44AM +0100, Jakub Jelinek wrote:
> On Fri, Mar 12, 2021 at 04:08:17AM +0100, David Lamparter wrote:
> >
> > The TYPE_MAIN_VARIANT() here was, for casts to a typedef'd type name,
> > resulting in all information about the typedef's involvement getting
> > lost. This d
(CC’ing gcc-patch alias).
Hi, Kees,
> On Mar 12, 2021, at 3:55 PM, Kees Cook wrote:
>
> On Fri, Mar 12, 2021 at 03:35:28PM -0600, Qing Zhao wrote:
>> Hi, Kees,
>>
>> I am looking at the structure padding initialization issue. And also have
>> some questions:
>>
>>
>>> On Feb 24, 2021, at 1
Iain Sandoe wrote:
Iain Sandoe wrote:
Jason Merrill wrote:
I notice this patch includes
+ var_nest_node () = default;
which will break GCC 10 bootstrap with a C++98 compiler; we only
switched to C++11 for GCC 11.
Hmm, the patch was already backported…
… I will fix this.
I missed the
On Wed, 3 Mar 2021 at 15:00, Richard Earnshaw
wrote:
>
> On 02/03/2021 18:35, Christophe Lyon wrote:
> > On Tue, 2 Mar 2021 at 19:18, Richard Earnshaw
> > wrote:
> >>
> >> On 02/03/2021 18:14, Richard Earnshaw via Gcc-patches wrote:
> >>> On 02/03/2021 18:10, Christophe Lyon wrote:
> On Tue,
On 02/03/2021 23:37, Ilya Leoshkevich wrote:
> Bootstrapped and regtested on x86_64-redhat-linux, ppc64le-redhat-linux
> and s390x-redhat-linux. Ok for master?
>
>
>
> Commit efb6bc55a93a ("fwprop: Allow (subreg (mem)) simplifications")
> introduced a check that was supposed to look at the prop
The following makes FRE optimize a load we formerly required
SRA + CCP for which now run after we get rid of all __builtin_constant_p
calls.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
2021-03-15 Richard Biener
PR tree-optimization/98834
* tree-ssa-sccvn.c (vn
> The change is supposed to be binary compatible so not sure what this
> means.
Our problem is related with distribution, not with a specific library
or its ABI. Imagine that:
$VENDOR1 builds GNAT without the fix.
$VENDOR2 builds libfoo against GNAT.
$administrator installs both.
I write bar.ad
Applied to all three branches, after regtesting on each, as blindingly
obvious. The testcase is the reduced version in comment #6 of the PR.
Paul
Fortran: Fix problem with allocate initialization [PR99545].
2021-03-15 Paul Thomas
gcc/fortran/ChangeLog
PR fortran/99545
* trans-stmt.c (gfc_tr
On 15/03/21 10:18 -0400, Patrick Palka via Libstdc++ wrote:
This implements operator++, operator-- and operator<=> for the
integer-class types defined in max_size_type.h, which I overlooked
when originally implementing the class.
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
OK,
This implements operator++, operator-- and operator<=> for the
integer-class types defined in max_size_type.h, which I overlooked
when originally implementing the class.
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
libstdc++-v3/ChangeLog:
* include/bits/max_size_type.h (__
On Mon, Mar 15, 2021 at 08:31:09AM -0400, Nathan Sidwell wrote:
> On 3/11/21 3:58 PM, Marek Polacek via Gcc-patches wrote:
> > I was looking at the LCOV coverage report for the C++ FE and
> > found a bunch of unused functions that I think we can remove.
> > Obviously, I left alone various dump_* an
On Sun, Feb 14, 2021 at 9:26 AM H.J. Lu wrote:
>
> Check if host supports multi-byte NOPs before enabling CET on host.
>
> config/
>
> PR binutils/27397
> * cet.m4 (GCC_CET_HOST_FLAGS): Check if host supports multi-byte
> NOPs.
>
> libiberty/
>
> PR binutils/27397
>
On 3/11/21 3:58 PM, Marek Polacek via Gcc-patches wrote:
I was looking at the LCOV coverage report for the C++ FE and
found a bunch of unused functions that I think we can remove.
Obviously, I left alone various dump_* and debug_* routines.
I haven't removed cp_build_function_call although it is
On 12/03/21 15:33 -0800, Caroline Tice wrote:
I have updated the patch as you suggested, to filter the
"-fvtable-verify=std" out of AM_CXXFLAGS, and I have verified that it
passes the testsuite with no regressions and fixes the reported bug.
This means we also don't pass it to LTCXXCOMPILE, ins
On Mon, 2021-03-15 at 09:32 +0100, Martin Liška wrote:
> Fixes the following valid clang warning:
>
> gcc/analyzer/sm-file.cc:250:5: warning: suspicious concatenation of
> string literals in an array initialization;
> did you mean to separate the elements with a comma? [-Wstring-
> concatenation]
On 15/03/21 00:34 +, Iain Sandoe wrote:
Hi
We need to add the symbols for to_chars and from_chars for the
long double cases.
The testsuite test cases fail to build without this, so there’s no need
for an additional test.
Tested on powerpc-darwin9.
OK for master?
OK, thanks.
thanks
Iai
On 15/03/21 00:40 +, Iain Sandoe wrote:
Hi,
What is slightly odd here is that this problem shows up for
installed testing, but not when the test-suite is run in-tree.
However, the issue is clear (and doesn’t need to depend on
figuring out why it doesn’t show in-tree).
tested on powerpc-dar
Iain Sandoe wrote:
Although this is an Objective-C++ patch, I need to touch stuff outside
“objc local”
contexts, so think it needs review,
(this is a regression fix for all open branches).
Iain Sandoe wrote:
We were discussing proposed reflection splicing syntax - [:reflection:]
in SG7
On 3/14/21 8:29 PM, Iain Sandoe wrote:
Hi
The awaiter.await_ready() should be converted per [expr.await]/3
(3.6) await-ready is the expression e.await_ready(), contextually
converted to bool.
The conversion had been omitted, fixed as below,
tested on x86_64-darwin, x86_64-linux-gnu, an
On 3/14/21 8:25 PM, Iain Sandoe wrote:
Hi
Although there is still some discussion in CWG2451 on this, the
implementors are agreed on the intent (thus it is wording that is
expected to change - the implementations should be brought into
sync).
tested on x86_64-darwin, x86_64-linux-gnu and with c
On 3/14/21 8:22 PM, Iain Sandoe wrote:
Hi
Apparently, I had a brainstorm when posting patches to cover the
cases with await expressions in do {} while; and while {} ; and
omitted the for loop case.
Fixed thus.
tested on x86_64-darwin, x86_64-linux-gnu and with cppcoro and
folly/coroutines.
O
On 3/14/21 8:17 PM, Iain Sandoe wrote:
Hi
In the compiler-only idiom:
" a = (target expr creates temp, op uses temp)"
the target expression variable needs to be promoted to a frame one
(if the expression has a suspend point). However, the only uses of
the var are in the second part of the compo
Hi,
I plan to commit some retuning of znver3 codegen that is based on real
hardware benchmarks. It turns out that there are not too many changes
necessary sinze Zen3 is quite smooth upgrade to Zen2. In summary:
- some instructions (like idiv) have shorter latencies. Adjusting
costs reduces
Fixes the following valid clang warning:
gcc/analyzer/sm-file.cc:250:5: warning: suspicious concatenation of string
literals in an array initialization;
did you mean to separate the elements with a comma? [-Wstring-concatenation]
Survives make check -k RUNTESTFLAGS="analyzer.exp".
Ready to be
Fix the following clang warning:
gcc/spellcheck.c:477:3: warning: suspicious concatenation of string literals in
an array initialization;
did you mean to separate the elements with a comma? [-Wstring-concatenation]
It's quite obvious issue in unit tests, thus I'm going to push it.
Martin
gcc
Hello Thomas, hello World,
On 14.03.21 21:18, Thomas Koenig via Fortran wrote:
the attached, rather obvious patch fixes an ICE on valid which
came about because I did not handle EXEC_IOLENGTH as start of
an I/O statement when checking for the DO loop variable.
This is an 11 regression.
Thanks t
On Mon, Mar 15, 2021 at 09:17:47AM +0100, Tobias Burnus wrote:
> gcc/c/ChangeLog:
>
> PR c++/99509
> * c-decl.c (finish_decl): For 'omp declare target implicit' vars,
> ensure that the varpool node is marked as offloadable.
>
> gcc/cp/ChangeLog:
>
> PR c++/99509
> *
On 12.03.21 13:20, Jakub Jelinek wrote:
On Wed, Mar 10, 2021 at 03:20:42PM +0100, Tobias Burnus wrote:
The C/C++ FE sets for an 'omp declare target' ... 'omp end declare target'
the attribute 'omp declare target implicit'.
That's later processed (for C++) in decl.c - which remove that attribute
36 matches
Mail list logo
