Hi.
I'd like to know what's the status of the review for this patch.
(Same for my other patch 96889: add some reflection functions in the jit
C api)
Thanks.
On Tue, Jul 21, 2020 at 11:29:57PM +0200, Andrea Corallo wrote:
Hi Antoni,
a couple of nits and some thoughts.
Antoni Boucher via Gcc-p
On Wed, 2021-02-10 at 19:42 +, brian.sobulefsky wrote:
Hi Brian
Thanks for the patch.
The patch is large enough to count as legally significant; I've sent
you information on copyright assignment separately; the patch can't be
committed until that paperwork is in place.
In the meantime, I've
On Fri, Feb 12, 2021 at 02:50:12PM -0600, Peter Bergner wrote:
> The rs6000_emit_le_vsx_* functions assume they are not passed an Altivec
> style "& ~16" address. However, some of our expanders and splitters do
> not verify we do not have an Altivec style address before calling those
> functions,
Here, the problem ultimately seems to be that tsubst_copy_and_build,
when called with empty args as we do during non-dependent expression
folding, doesn't touch BASELINKs at all: it delegates to tsubst_copy
which then immediately exits early due to the empty args. This means
that the CAST_EXPR int
This makes instantiation_dependent_expression_p avoid checking
potential_constant_expression when processing_template_decl isn't set
(and hence when value_dependent_expression_p is definitely false).
gcc/cp/ChangeLog:
* pt.c (instantiation_dependent_expression_p): Check
processing
On 2/12/21 4:21 PM, Peter Bergner wrote:
> rtl-optimization: Fix uninitialized use of opaque mode variable ICE [PR98872]
>
> The initialize_uninitialized_regs function emits (set (reg:) (CONST0_RTX))
> for all uninitialized pseudo uses. However, some modes (eg, opaque modes)
> may not have a CONS
We represent deduction guides with FUNCTION_DECLs, but they are built
without DECL_CONTEXT, leading to an ICE in type_dependent_expression_p
on the assert that the type of a function template with no dependent
(innermost!) template arguments must be non-dependent. Consider the
attached class-deduc
On Thu, Feb 11, 2021 at 03:03:38PM +, Richard Sandiford via Gcc-patches
wrote:
> gcc/
> * df-problems.c (df_lr_bb_local_compute): Treat partial definitions
> as read-modify operations.
>
> gcc/testsuite/
> * gcc.dg/rtl/aarch64/multi-subreg-1.c: New test.
The test fails ever
On 2/8/21 7:29 AM, Segher Boessenkool wrote:
>> I think we should either add a new rtx code for constant opaque modes
>> or make init-regs just emit the clobber for opaque modes (and not emit
>> the move).
>
> Thanks for looking Richard. That last option sounds good to me as well.
Ok, guarding t
As mentioned in 99040's fix, we can get inter-module using decls. If
the using decl is the only reference to an import, we'll have failed to
seed our imports leading to an assertion failure. The fix is
straight-forwards, check binding contents when seeding imports.
gcc/cp/
With modules one can have using-decls refering to their own scope. This
is the way to export things from the GMF or from an import. The problem
was I was using current_ns == CP_DECL_CONTEXT (decl) to determine
whether a decl should be registered in a namespace level or not. But
that's an ina
IDENTIFIER_TYPE_VALUE and friends is a remnant of G++'s C origins. It
holds elaborated types on identifier-nodes. While this is fine for C
and for local and class-scopes in C++, it fails badly for namespaces. In
that case a marker 'global_type_node' was used, which essentially
signified 'this
I merged trunk revision 9769564e7456453e2273071d0faa5aab2554ff78 to
the gccgo branch.
Ian
The rs6000_emit_le_vsx_* functions assume they are not passed an Altivec
style "& ~16" address. However, some of our expanders and splitters do
not verify we do not have an Altivec style address before calling those
functions, leading to an ICE. The solution here is to guard the expanders
and spl
On 2/12/21 12:36 PM, Richard Biener wrote:
On February 12, 2021 7:21:25 PM GMT+01:00, Martin Sebor
wrote:
On 2/12/21 12:35 AM, Richard Biener wrote:
On Thu, Feb 11, 2021 at 7:35 PM Martin Sebor
wrote:
On 2/11/21 12:59 AM, Richard Biener wrote:
On Wed, Feb 10, 2021 at 6:16 PM Martin Sebor
On February 12, 2021 7:21:25 PM GMT+01:00, Martin Sebor
wrote:
>On 2/12/21 12:35 AM, Richard Biener wrote:
>> On Thu, Feb 11, 2021 at 7:35 PM Martin Sebor
>wrote:
>>>
>>> On 2/11/21 12:59 AM, Richard Biener wrote:
On Wed, Feb 10, 2021 at 6:16 PM Martin Sebor
>wrote:
>
> The attache
This patch by Michael Matloob fixes the Go frontend to use the correct
path when opening an embedded file for a string or []byte type. For
the other embed.FS case we were correctly using the Files mapping, but
for string or []byte we were not. Bootstrapped and ran Go testsuite
on x86_64-pc-linux-
On 2/11/21 5:14 PM, Patrick Palka wrote:
On Thu, 11 Feb 2021, Jason Merrill wrote:
On 2/8/21 2:03 PM, Patrick Palka wrote:
This fixes the way we check satisfaction of constraints on placeholder
types in various contexts, and in particular when the constraint is
dependent.
Firstly, when evalua
On 2/10/21 9:41 AM, Patrick Palka wrote:
On Tue, 9 Feb 2021, Jason Merrill wrote:
On 2/8/21 2:03 PM, Patrick Palka wrote:
This sets up the functionality for controlling the initial set of
template parameters to pass to normalization when dealing with a
constraint-expression that is not associa
On 2/12/21 9:56 AM, Martin Sebor wrote:
On 2/12/21 2:09 AM, Richard Biener via Gcc-patches wrote:
On Thu, Feb 11, 2021 at 6:41 PM Martin Liška wrote:
Hello.
This fixes 2 memory leaks I noticed.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
On 2/12/21 12:35 AM, Richard Biener wrote:
On Thu, Feb 11, 2021 at 7:35 PM Martin Sebor wrote:
On 2/11/21 12:59 AM, Richard Biener wrote:
On Wed, Feb 10, 2021 at 6:16 PM Martin Sebor wrote:
The attached patch replaces calls to print_generic_expr_to_str() with
a helper function that returns
On 12/02/2021 17:21, Christophe Lyon wrote:
> On Fri, 12 Feb 2021 at 17:02, Richard Earnshaw
> wrote:
>>
>> On 12/02/2021 14:20, Christophe Lyon via Gcc-patches wrote:
>>> This test forces -march=armv8.1-m.main, which supports only Thumb mode.
>>> However, if the toolchain is not configured --with
On Fri, 12 Feb 2021 at 17:02, Richard Earnshaw
wrote:
>
> On 12/02/2021 14:20, Christophe Lyon via Gcc-patches wrote:
> > This test forces -march=armv8.1-m.main, which supports only Thumb mode.
> > However, if the toolchain is not configured --with-thumb, the test
> > fails with:
> > error: target
On 2/12/21 2:09 AM, Richard Biener via Gcc-patches wrote:
On Thu, Feb 11, 2021 at 6:41 PM Martin Liška wrote:
Hello.
This fixes 2 memory leaks I noticed.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
OK.
Thanks,
Martin
gcc/ChangeLog:
How do I get permissions set so that I can change status of bug reports
and assign to myself. My permissions got dissolved during some
evolution in the last year.
also
The master branch has been updated by Jerry DeLisle:
https://gcc.gnu.org/g:0631e008adc759cc801d0d034224ee6b4bcf31aa
commit
The rtl-ssa code uses an on-the-side IL and needs to build that IL
for each block and RTL insn. I'd originally not used the classical
dominance frontier method for placing phis on the basis that it seemed
like more work in this context: we're having to visit everything in
an RPO walk anyway, so fo
On 12/02/2021 14:20, Christophe Lyon via Gcc-patches wrote:
> This test forces -march=armv8.1-m.main, which supports only Thumb mode.
> However, if the toolchain is not configured --with-thumb, the test
> fails with:
> error: target CPU does not support ARM mode
>
> Adding -mthumb to dg-options fi
I noticed while working on PR98863 that we were using the main
obstack to allocate temporary uses. That was safe, but represents
a kind of local memory leak.
Tested on aarch64-linux-gnu and x86_64-linux-gnu, pushed as obvious.
Richard
gcc/
* rtl-ssa/accesses.cc (function_info::make_use
The _wrename function won't overwrite an existing file, so use
MoveFileEx instead. That allows renaming directories over files, which
POSIX doesn't allow, so check for that case explicitly and report an
error.
Also document the deviation from the expected behaviour, and add a test
for filesystem::
On 10/02/21 16:58 +, Jonathan Wakely wrote:
This wasn't fixed upstream for mingw-w64 so we still need the
workaround.
libstdc++-v3/ChangeLog:
PR libstdc++/1
* src/c++17/fs_ops.cc (fs::status): Re-enable workaround.
Oops, the same change is needed in symlink_status as w
This patch disallows selecting components of array sections in update
directives for OpenACC, as specified in OpenACC 3.0, "2.14.4. Update
Directive", "Restrictions":
"In Fortran, members of variables of derived type may appear, including
a subarray of a member. Members of subarrays of derive
This patch fixes lowering of derived-type mappings which select elements
of arrays of derived types, and similar. These would previously lead
to ICEs.
With this change, OpenACC directives can pass through constructs that
are no longer recognized by the gimplifier, hence alterations are needed
ther
This series contains an updated version of the "3/4" patch from this
series:
https://gcc.gnu.org/pipermail/gcc-patches/2021-February/564711.html
together with bits that undo the reversions in:
https://gcc.gnu.org/pipermail/gcc-patches/2021-February/565093.html
and a new approach to handling
On 12/02/21 15:12 +, Jonathan Wakely wrote:
@@ -364,9 +378,7 @@ namespace ip
static constexpr address_v6
loopback() noexcept
{
- address_v6 __addr;
- __addr._M_bytes[15] = 1;
- return __addr;
+ return {bytes_type{0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1}};
}
Oops,
Nope. I can't reach Robert, so CC MIPS maintainer.
On 2021-02-12 22:57 +0800，Xi Ruoyao wrote:
> Well, it just dislike my mail server :(. Switch to the mail server of my
> university.
>
> On 2021-02-12 22:54 +0800, Xi Ruoyao wrote:
> > Resend the mail. I had to fill in a form to send mail to Ro
The helper function for creating new paths doesn't work well on Windows,
because the PID of a process started by Wine is very consistent and so
the same path gets created each time.
libstdc++-v3/ChangeLog:
* testsuite/util/testsuite_fs.h (nonexistent_path): Add
random number to th
libstdc++-v3/ChangeLog:
* include/experimental/internet (address_v6::to_string): Include
scope ID in string.
* testsuite/experimental/net/internet/address/v6/members.cc:
Test to_string() results.
Tested powerpc64le-linux. Committed to trunk.
commit d1a821b93c45bfe
Well, it just dislike my mail server :(. Switch to the mail server of my
university.
On 2021-02-12 22:54 +0800, Xi Ruoyao wrote:
> Resend the mail. I had to fill in a form to send mail to Robert.
>
> On 2021-02-12 22:17 +0800, Xi Ruoyao wrote:
> > On 2021-01-11 01:01 +0800, Xi Ruoyao wrote:
> >
Resend the mail. I had to fill in a form to send mail to Robert.
On 2021-02-12 22:17 +0800, Xi Ruoyao wrote:
> On 2021-01-11 01:01 +0800, Xi Ruoyao wrote:
> > Hi Jeff and Jakub,
> >
> > On 2021-01-04 14:19 -0700, Jeff Law wrote:
> > > On 1/4/21 2:00 PM, Jakub Jelinek wrote:
> > > > On Mon, Jan 0
This avoids some warnings when building with -fno-rtti because the
function parameters are only used when RTTI is enabled.
libstdc++-v3/ChangeLog:
* include/bits/shared_ptr_base.h (__shared_ptr::_M_get_deleter):
Add unused attribute to parameter.
* src/c++11/shared_ptr.cc
libstdc++-v3/ChangeLog:
* include/experimental/internet (address_v6::any): Avoid using
memcpy in constexpr function.
(address_v6::loopback): Likewise.
(make_address_v6): Fix missing return statements on error paths.
* include/experimental/io_context: Avoid -
The std::emit_on_flush manipulator depends on dynamic_cast, so fails
without RTTI.
The std::async code can't catch a forced_unwind exception when RTTI is
disabled, so it can't rethrow it either, and the test aborts.
libstdc++-v3/ChangeLog:
* testsuite/27_io/basic_ostream/emit/1.cc: Expec
libstdc++-v3/ChangeLog:
* include/std/ostream (__syncbuf_base::_S_get): Mark parameter
as unused and only use dynamic_cast when RTTI is enabled.
Tested powerpc64le-linux. Committed to trunk.
commit 14b554c462d5b6450fa24afb7ba55435ebd4b46f
Author: Jonathan Wakely
Date: Fri Feb
libstdc++-v3/ChangeLog:
* testsuite/util/testsuite_allocator.h (memory_resource):
Remove requirement for RTTI and exceptions to be enabled.
Tested powerpc64le-linux. Committed to trunk.
commit 0bd242ec5aeffd1fb2a3ee16a2c69afae2aff2ce
Author: Jonathan Wakely
Date: Fri Feb 12 11
libstdc++-v3/ChangeLog:
* testsuite/27_io/basic_istringstream/rdbuf/char/2832.cc: Use
static_cast when RTTI is disabled.
* testsuite/27_io/basic_istringstream/rdbuf/wchar_t/2832.cc:
Likewise.
* testsuite/27_io/basic_ostringstream/rdbuf/char/2832.cc:
On 12/02/21 12:31 +0100, Mirko Vogt wrote:
On 2/12/21 11:30 AM, Jonathan Wakely wrote:
This patch is wrong.
Indeed, thanks for checking.
If you simply disable that function definition
for !__cpp_rtti then you'll get linker errors from fstream.tcc when
that function is called.
/usr/bin/ld:
On Fri, Jan 29, 2021 at 7:53 AM Jakub Jelinek via Gcc-patches
wrote:
>
> On Thu, Jan 21, 2021 at 07:33:34PM +, Kwok Cheung Yeung wrote:
> > The detach support clearly needs more work, but is this particular patch
> > okay for trunk?
>
> Sorry for the delay.
>
> I'm afraid it is far from being
This test forces -march=armv8.1-m.main, which supports only Thumb mode.
However, if the toolchain is not configured --with-thumb, the test
fails with:
error: target CPU does not support ARM mode
Adding -mthumb to dg-options fixes the problem.
Committed as obvious.
2021-02-12 Christophe Lyon
On 2021-01-11 01:01 +0800, Xi Ruoyao wrote:
> Hi Jeff and Jakub,
>
> On 2021-01-04 14:19 -0700, Jeff Law wrote:
> > On 1/4/21 2:00 PM, Jakub Jelinek wrote:
> > > On Mon, Jan 04, 2021 at 01:51:59PM -0700, Jeff Law via Gcc-patches wrote:
> > > > > Sorry, I forgot to include the ChangeLog:
> > > > >
Hi All,
Following off-list discussion with Tobias, I have committed the patch as
submitted to 10- and 11-branches.
A rather general problem with parsing and matching, which arose from the
discussion, has been shunted into PR99065. If possible, I intend to fix
this by two pass parsing/matching of
Hi Tobias,
The patch is good for 10- and 11-branches.
Thanks
Paul
On Thu, 11 Feb 2021 at 18:59, Tobias Burnus wrote:
> In the Fortran standard, I think it is best explained
> in the description of the RANK intrinsic:
>
> "Example. If X is an assumed-rank dummy argument and
> its associated e
On Thu, Feb 11, 2021 at 11:19 AM Alexandre Oliva wrote:
>
> On Feb 4, 2021, Alexandre Oliva wrote:
>
> > On Feb 4, 2021, Richard Biener wrote:
> >>> > b) if expansion would use BY_PIECES then expand to an unrolled loop
> >>>
> >>> Why would that be better than keeping the constant-length mems
On 2/12/21 11:30 AM, Jonathan Wakely wrote:
This patch is wrong.
Indeed, thanks for checking.
If you simply disable that function definition
for !__cpp_rtti then you'll get linker errors from fstream.tcc when
that function is called.
/usr/bin/ld:
/home/jwakely/src/gcc/build/x86_64-pc-linux-
The walk_aliased_vdef calls do not update the walking budget until
it is hit by a single call (and then in one case it resumes with
no limit at all). The following rectifies this in multiple places.
It also makes the updates more consistend and fixes
determine_known_aggregate_parts to account its
On Fri, Feb 12, 2021 at 10:59 AM Richard Sandiford
wrote:
>
> Richard Biener writes:
> > On Thu, Feb 11, 2021 at 4:33 PM Richard Sandiford via Gcc-patches
> > wrote:
> >>
> >> df_lr_bb_local_compute has:
> >>
> >> FOR_EACH_INSN_INFO_DEF (def, insn_info)
> >> /* If the def is to onl
>Hello,
>
>ran into the following when building libstdc++ without rtti support:
>
>libstdc++-v3/src/c++11/cxx11-ios_failure.cc:174:54: error: no matching
>function for call to 'std::ios_base::failure::failure(const char*&, int&)'
>
>Attached patch does as follows:
Libstdc++ patches need to be CC'
Richard Biener writes:
> On Thu, Feb 11, 2021 at 4:33 PM Richard Sandiford via Gcc-patches
> wrote:
>>
>> df_lr_bb_local_compute has:
>>
>> FOR_EACH_INSN_INFO_DEF (def, insn_info)
>> /* If the def is to only part of the reg, it does
>>not kill the other defs that reach h
Hi!
The vla15.C testcase ICEs with
-mcpu=cortex-m1 -mpure-code -fstack-protector -mthumb
as what force_const_mem returns (a SYMBOL_REF) is not a valid
memory address.
Previously the code was moving the address of the force_const_mem
into a register rather than the content of that MEM, so that inst
On Thu, Feb 11, 2021 at 6:41 PM Martin Liška wrote:
>
> Hello.
>
> This fixes 2 memory leaks I noticed.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
OK.
> Thanks,
> Martin
>
> gcc/ChangeLog:
>
> * opts-common.c (decode_cmdline_opti
On Thu, Feb 11, 2021 at 4:33 PM Richard Sandiford via Gcc-patches
wrote:
>
> df_lr_bb_local_compute has:
>
> FOR_EACH_INSN_INFO_DEF (def, insn_info)
> /* If the def is to only part of the reg, it does
>not kill the other defs that reach here. */
> if (!(DF_REF_FL
On Fri, Feb 12, 2021 at 1:35 AM Martin Sebor via Gcc-patches
wrote:
>
> While trawling through old bugs I came across one from 2005: PR 21433
> - The COMPONENT_REF case of expand_expr_real_1 is probably wrong.
>
> The report looks correct in that argument 0 in COMPONENT_REF cannot
> be a CONSTRUCT
On Thu, Feb 11, 2021 at 11:26 PM Martin Sebor wrote:
>
> On 2/11/21 1:09 AM, Richard Biener wrote:
> > On Wed, Feb 10, 2021 at 7:03 PM Martin Sebor wrote:
> >>
> >> On 2/10/21 3:39 AM, Richard Biener wrote:
> >>> On Tue, Feb 9, 2021 at 4:37 PM Martin Sebor wrote:
>
> On 2/9/21 12:41 AM
62 matches
Mail list logo
