From: Sinan Lin
Third operand of cpymem pattern is unsigned HOST_WIDE_INT, however we
are interpret that as signed HOST_WIDE_INT, that not a problem in
most case, but when the value is large than signed HOST_WIDE_INT, it
might screw up since we have using that value to calculate the buffer
size.
From: Naveen H S
Please find attached the patch that modifies "__ARM_ARCH" as per latest ACLE.
Built and tested the patch on aarch64-marvell-linux-gnu.
Please review the patch and let me know if it's okay.
2021-04-03 Naveen H S
PR tree-optimization/99312
* config/aarch64/aar
On Thu, 4 Mar 2021, Patrick Palka wrote:
> On Thu, 4 Mar 2021, Patrick Palka wrote:
>
> > On Thu, 4 Mar 2021, Jason Merrill wrote:
> >
> > > On 3/4/21 11:32 AM, Patrick Palka wrote:
> > > > On Thu, 4 Mar 2021, Patrick Palka wrote:
> > > >
> > > > > My recent r11-7454 changed the way do_auto_ded
This PR complains that we issue a -Wconversion warning in
template struct X {};
template X foo();
saying "conversion from 'long unsigned int' to 'int' may change value".
While it's not technically wrong, I suspect -Wconversion warnings aren't
all that useful for value-dependent expressions.
Tested cris-elf and x86_64-linux to eliminate the edit being
fatfingered.
The test is still failing and is a regression on master for
cris-elf: the remedy for (all) other targets wasn't
sufficient. I'm not myself going to put any effort into it
(debug-information being different enough for a test
OK, thanks Dominique for spotting this.
On 3/4/21 9:02 AM, Tobias Burnus wrote:
Dominique found an issue ("regression") with this patch – and a testcase
omission.
The previous patch mishandled the noncommitted testcase of PR57871 – or
in other words: It did not promote 1.0_4 or 1.0_8 – as only
The issue in this PR is that we wrongly reject converting pointers to
member function of incomplete types, one of which has noexcept. Recall
that pointers (including pointers to member functions) to non-throwing
functions can be implicitly converted to potentially-throwing functions
(but not vice
On Thu, 4 Mar 2021, Patrick Palka wrote:
> On Thu, 4 Mar 2021, Jason Merrill wrote:
>
> > On 3/4/21 11:32 AM, Patrick Palka wrote:
> > > On Thu, 4 Mar 2021, Patrick Palka wrote:
> > >
> > > > My recent r11-7454 changed the way do_auto_deduction handles constrained
> > > > placeholders during tem
On Thu, 4 Mar 2021, Jason Merrill wrote:
> On 3/4/21 11:32 AM, Patrick Palka wrote:
> > On Thu, 4 Mar 2021, Patrick Palka wrote:
> >
> > > My recent r11-7454 changed the way do_auto_deduction handles constrained
> > > placeholders during template argument deduction (context == adc_unify)
> > > wh
[PATCH 2/2 V3] Do not build Decimal/Float128 conversions if
--disable-decimal-float.
This patch disables building the Decimal/_Float128 conversion functions if the
user configured the compiler with the --disable-decimal-float option.
This is a much simpler patch to disable building the Decimal/F
On 3/4/21 11:32 AM, Patrick Palka wrote:
On Thu, 4 Mar 2021, Patrick Palka wrote:
My recent r11-7454 changed the way do_auto_deduction handles constrained
placeholders during template argument deduction (context == adc_unify)
when processing_template_decl != 0.
Before the patch, when processin
[PATCH V3] Require GLIBC 2.32 for Decimal/_Float128 conversions.
In the patch that I applied on March 2nd, I had code to provide support for
Decimal/_Float128 conversions if the user did not use at least GLIBC 2.32. It
did this by using __ibm128 as an intermediate type. The trouble is __ibm128
c
On 3/4/21 10:52 AM, Martin Liška wrote:
On 3/4/21 4:45 PM, Jason Merrill wrote:
Sure, I guess you do need to set that flag for the local decls, but
that should be all.
Jason
Doing that also fails :/
This time likely due to how we set RECORD argument of
maybe_version_functions function:
Committed to wwwdocs.
commit ed1a8d0621f5f5dee4d869393b9155f475d360f7
Author: Jonathan Wakely
Date: Thu Mar 4 20:51:52 2021 +
Add to libstdc++ header dependency changes
diff --git a/htdocs/gcc-11/porting_to.html b/htdocs/gcc-11/porting_to.html
index 83227c74..4d27c163 100644
--- a/ht
Hi Jerry,
> Yes, OK, however, have you been able to test performance. I am only
> curious. There was a test program we used back when this code was first
> implemented in bugzilla. I do not remember the PR number off hand.
as you mentioned in a private mail, it was PR51119, and the timing program
On 2/26/21 4:24 PM, Iain Sandoe wrote:
Hi,
The coroutine body is wrapped in a try-catch block which is responsible for
handling any exceptions thrown by the original function body. Originally, the
initial suspend expression was outside this, but an amendment to the standard
places the await_res
On 3/4/21 2:54 PM, Iain Sandoe wrote:
Hi,
From the PR:
The wording of [dcl.fct.def.coroutine]/15 states:
* The expression co_await promise.final_suspend() shall not be
potentially-throwing ([except.spec]).
See http://eel.is/c++draft/dcl.fct.def.coroutine#15
and http://eel.is/c++draft/ex
On 3/4/21 2:59 PM, Iain Sandoe wrote:
Hi,
PR98118 shows that TYPE_NEEDS_CONSTRUCTING is a necessary, but not
sufficient, condition for determining when we need to build a constructor.
Use type_build_ctor_call() instead.
tested on x86_64-darwin, x86_64-linux-gnu,
[ ice on valid ]
OK for master
On 3/4/21 12:44 PM, Martin Sebor wrote:
On 3/3/21 10:33 PM, Jason Merrill wrote:
On 3/3/21 6:20 PM, Martin Sebor wrote:
...
I see what you mean, thanks, but I can't think of a test case to
trigger a false negative due to the smaller offset. Any suggestions?
My only ideas involve undefined b
Hi,
PR98118 shows that TYPE_NEEDS_CONSTRUCTING is a necessary, but not
sufficient, condition for determining when we need to build a constructor.
Use type_build_ctor_call() instead.
tested on x86_64-darwin, x86_64-linux-gnu,
[ ice on valid ]
OK for master / 10.x?
thanks
Iain
gcc/cp/ChangeLog:
Hi,
>From the PR:
The wording of [dcl.fct.def.coroutine]/15 states:
* The expression co_await promise.final_suspend() shall not be
potentially-throwing ([except.spec]).
See http://eel.is/c++draft/dcl.fct.def.coroutine#15
and http://eel.is/c++draft/except.spec#6
ie. all of the following must
On 3/3/21 10:33 PM, Jason Merrill wrote:
On 3/3/21 6:20 PM, Martin Sebor wrote:
...
I see what you mean, thanks, but I can't think of a test case to
trigger a false negative due to the smaller offset. Any suggestions?
My only ideas involve undefined behavior, casting the address to a
pointe
Dominique found an issue ("regression") with this patch – and a testcase
omission.
The previous patch mishandled the noncommitted testcase of PR57871 – or
in other words: It did not promote 1.0_4 or 1.0_8 – as only the
default-real-kind values 1.0 and 1.0d0 were promoted (via code in in
trans-typ
Hi,
this is an undefined behavior spotted by the sanitizer that has managed to go
unnoticed until now. Tested on x86-64/Linux, OK for the mainline?
2021-03-04 Eric Botcazou
PR rtl-optimization/99376
* rtlanal.c (nonzero_bits1) : If the number
of low-order zero bits
On Thu, 2021-03-04 at 16:17 +, Philip Herron wrote:
> In development of the Rust FE logging is useful in debugging. Instead
> of
> rolling our own logger it became clear the loggers part of analyzer
> and jit
> projects could be extracted and made generic so they could be reused
> in
> other pr
Hi!
On 2021-02-19T13:59:20+0100, Tobias Burnus wrote:
> For:
>#pragma acc parallel async(1,2)
>
> avoid with C an ICE for the original tree:
>#pragma acc parallel async(<<< Unknown tree: c_maybe_const_expr 1, 2 >>>)
>
> It did not ICE with C++, but I think the tree does not make sense, ei
On Thu, 4 Mar 2021, Patrick Palka wrote:
> My recent r11-7454 changed the way do_auto_deduction handles constrained
> placeholders during template argument deduction (context == adc_unify)
> when processing_template_decl != 0.
>
> Before the patch, when processing_template_decl != 0 we would just
My recent r11-7454 changed the way do_auto_deduction handles constrained
placeholders during template argument deduction (context == adc_unify)
when processing_template_decl != 0.
Before the patch, when processing_template_decl != 0 we would just
ignore the constraints on the placeholder in this s
In development of the Rust FE logging is useful in debugging. Instead of
rolling our own logger it became clear the loggers part of analyzer and jit
projects could be extracted and made generic so they could be reused in
other projects.
To test this patch make check-jit was invoked, for analyzer t
On 3/4/21 2:11 AM, Jakub Jelinek wrote:
> Hi!
>
> The following testcase ICEs on aarch64. The problem is that
> op0 is (subreg:HI (reg:HF ...) 0) and because we can't create a SUBREG of a
> SUBREG and aarch64 doesn't have HImode insv, only SImode insv,
> store_bit_field_using_insv tries to crea
On 3/4/21 4:45 PM, Jason Merrill wrote:
Sure, I guess you do need to set that flag for the local decls, but that should
be all.
Jason
Doing that also fails :/
This time likely due to how we set RECORD argument of maybe_version_functions
function:
gcc/cp/decl.c:&& maybe_version_function
On 3/4/21 5:51 AM, Richard Biener wrote:
> The gcc.dg/noncompile/pr79758.c testcase prints
>
> pr79758.c:5:6: error: redefinition of 'fn1'
> 'error_mark' not supported by
> direct_abstract_declarator)'/home/rguenther/src/gcc3/gcc/testsuite/gcc.dg/noncompile/pr79758.c:4:6:
> note: previous defi
On 3/4/21 1:53 AM, Mike Frysinger via Gcc-patches wrote:
> I'm not entirely sure why this is here since the sim doesn't use
> anything from the gdb/ dir directly, and the commit that added it
> included a bunch more changes and doesn't seem to call out this
> dep specifically.
>
> ChangeLog:
>
>
On 3/4/21 10:39 AM, Martin Liška wrote:
On 3/4/21 4:03 PM, Jason Merrill wrote:
Do you really need to register all these pairs? I was expecting that
you'd just look through DECL_LOCAL_DECL_ALIAS and then register the
pair you end up with. Local decls shouldn't need a cgraph node.
Well, doin
On 3/4/21 4:03 PM, Jason Merrill wrote:
Do you really need to register all these pairs? I was expecting that you'd
just look through DECL_LOCAL_DECL_ALIAS and then register the pair you end up
with. Local decls shouldn't need a cgraph node.
Well, doing that:
commit 662c486edafa467ec41091e
On 3/4/21 1:50 PM, Jan Hubicka wrote:
.../gcc.dg/tree-prof/indir-call-prof-malloc.c | 2 +-
gcc/testsuite/gcc.dg/tree-prof/pr97461.c | 2 +-
libgcc/libgcov-driver.c | 56 ---
3 files changed, 50 insertions(+), 10 deletions(-)
diff --git a/gcc/tes
On 3/4/21 3:19 AM, Martin Liška wrote:
On 3/2/21 6:57 PM, Jason Merrill wrote:
On 3/2/21 5:34 AM, Martin Liška wrote:
On 3/1/21 8:58 PM, Jason Merrill wrote:
On 3/1/21 11:59 AM, Martin Liška wrote:
On 3/1/21 5:36 PM, Jason Merrill wrote:
On 3/1/21 7:43 AM, Martin Liška wrote:
On 2/22/21 11:
Alex Coplan writes:
> Hi!
>
> As the PR shows, we were missing a check in
> function_resolver::require_vector_type to see if the argument type was already
> invalid. This was causing us to attempt to emit a diagnostic and subsequently
> ICE in print_type. Fixed thusly.
>
> Bootstrapped and regtest
On Thu, 2021-03-04 at 09:20 -0500, David Malcolm via Gcc-patches wrote:
> On Thu, 2021-03-04 at 09:39 +0100, Richard Biener wrote:
> > On Wed, 3 Mar 2021, Richard Biener wrote:
> >
> > > On Wed, 3 Mar 2021, David Malcolm wrote:
> > >
> > > > On Wed, 2021-03-03 at 08:48 +0100, Richard Biener wrote
On Thu, 2021-03-04 at 09:39 +0100, Richard Biener wrote:
> On Wed, 3 Mar 2021, Richard Biener wrote:
>
> > On Wed, 3 Mar 2021, David Malcolm wrote:
> >
> > > On Wed, 2021-03-03 at 08:48 +0100, Richard Biener wrote:
> > > > On Tue, 2 Mar 2021, Martin Sebor wrote:
> > > >
> > > > > On 3/2/21 9:52
v1: https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563799.html
v1 -> v2:
- Handle constraint modifiers, use AR constraint instead of R, add
testcases for & and %.
v2: https://gcc.gnu.org/pipermail/gcc-patches/2021-January/564380.html
v2 -> v3:
- The main prereq is now committed:
https:
Hi!
As the PR shows, we were missing a check in
function_resolver::require_vector_type to see if the argument type was already
invalid. This was causing us to attempt to emit a diagnostic and subsequently
ICE in print_type. Fixed thusly.
Bootstrapped and regtested on aarch64-linux-gnu. OK for tru
With pending entities reimplemented, the remaining use of uintset can
just use a regular hash map -- I only used a uintset because it was
there. So one adhoc hash-table/vector structure goes away.
PR c++/99170
gcc/cp/
* module.cc (class uintset): Delete.
(typed
On 3/4/21 4:53 AM, Jakub Jelinek wrote:
Hi!
In the P1771R1 changes JeanHeyd reverted part of Alex' PR88146 fix,
but that seems to be incorrect to me.
Where P1771R1 suggests warnings for [[nodiscard]] on constructors is
handled in a different place - in particular the TARGET_EXPR handling
of conv
On 3/4/21 4:03 AM, Jakub Jelinek wrote:
Hi!
In libcpp, lines are represented as linenum_type, which is unsigned int.
The following testcases ICE because maybe_print_line_1 is sometimes called
with UNKNOWN_LOCATION (e.g. at pragma eof) and while most of the time
the
&& src_line >= print.s
The gcc.dg/noncompile/pr79758.c testcase prints
pr79758.c:5:6: error: redefinition of 'fn1'
'error_mark' not supported by
direct_abstract_declarator)'/home/rguenther/src/gcc3/gcc/testsuite/gcc.dg/noncompile/pr79758.c:4:6:
note: previous definition of 'fn1' with type
which shows a) re-entry of p
> .../gcc.dg/tree-prof/indir-call-prof-malloc.c | 2 +-
> gcc/testsuite/gcc.dg/tree-prof/pr97461.c | 2 +-
> libgcc/libgcov-driver.c | 56 ---
> 3 files changed, 50 insertions(+), 10 deletions(-)
>
> diff --git a/gcc/testsuite/gcc.dg/tree-prof/indir-ca
This patch addresses 99170. with modules (and in particular header
units), one module can provide a (maybe nested) class or template and
another module can provide a definition or (maybe partial)
specialization of said entity, or member thereof. when both are
imported into a 3rd TU, and tha
On Thu, 4 Mar 2021, Richard Biener wrote:
> On Wed, 3 Mar 2021, Richard Biener wrote:
>
> > On Wed, 3 Mar 2021, David Malcolm wrote:
> >
> > > On Wed, 2021-03-03 at 08:48 +0100, Richard Biener wrote:
> > > > On Tue, 2 Mar 2021, Martin Sebor wrote:
> > > >
> > > > > On 3/2/21 9:52 AM, Jeff Law v
Pushed as obvious.
Martin
libgcc/ChangeLog:
PR gcov-profile/99385
* libgcov.h (allocate_gcov_kvp): Call mmap with fd equal to -1.
---
libgcc/libgcov.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libgcc/libgcov.h b/libgcc/libgcov.h
index 9c5fcfba4ad..acdb
This seems to be a typo/thinko in the definition of the arrays used as
storage.
libstdc++-v3/ChangeLog:
PR libstdc++/99382
*
testsuite/20_util/specialized_algorithms/uninitialized_default_n/sizes.cc:
Make storage larger than required. Verify no write to the last
e
On Thu, 4 Mar 2021, Jakub Jelinek wrote:
> On Thu, Mar 04, 2021 at 09:08:35AM +0100, Richard Biener wrote:
> > 2021-03-04 Richard Biener
> >
> > PR middle-end/97855
> > * tree-pretty-print.c: Poison pp_printf.
> > (dump_decl_name): Avoid use of pp_printf.
> > (dump_block_node):
On Thu, Mar 4, 2021 at 1:23 AM Ivan Sučić via Gcc-patches
wrote:
>
> Hi,
> The patch solves the bug when in ifcombine are comparisons like <= and >=
> combined. I removed the trap check for last statement and that doesn't break
> the solution for bug 61383. In fold-const.c i removed the trap che
Hello Kwok,
On 01.03.21 23:28, Kwok Cheung Yeung wrote:
When two or more nested loops are collapsed using the OpenMP collapse
clause, a single iteration variable is used to represent the combined
iteration space. In the usual case (i.e. statically scheduled, no
ordered clause), the type of this
Hi!
In the P1771R1 changes JeanHeyd reverted part of Alex' PR88146 fix,
but that seems to be incorrect to me.
Where P1771R1 suggests warnings for [[nodiscard]] on constructors is
handled in a different place - in particular the TARGET_EXPR handling
of convert_to_void. When we have CALL_EXPR of a
On Linux/x86_64,
d455130553544ee838b5215e76ccad22304cde39 is the first bad commit
commit d455130553544ee838b5215e76ccad22304cde39
Author: Jason Merrill
Date: Thu Feb 11 22:01:19 2021 -0500
cgraph: flatten and same_body aliases [PR96078]
caused
FAIL: gcc.dg/attr-flatten-1.c (test for war
Hi!
The following testcase ICEs on aarch64. The problem is that
op0 is (subreg:HI (reg:HF ...) 0) and because we can't create a SUBREG of a
SUBREG and aarch64 doesn't have HImode insv, only SImode insv,
store_bit_field_using_insv tries to create (subreg:SI (reg:HF ...) 0)
which is not valid for t
Hi!
In libcpp, lines are represented as linenum_type, which is unsigned int.
The following testcases ICE because maybe_print_line_1 is sometimes called
with UNKNOWN_LOCATION (e.g. at pragma eof) and while most of the time
the
&& src_line >= print.src_line
&& src_line < print.src_line
I'm not entirely sure why this is here since the sim doesn't use
anything from the gdb/ dir directly, and the commit that added it
included a bunch more changes and doesn't seem to call out this
dep specifically.
ChangeLog:
* Makefile.def: Remove all-sim dependency on configure-gdb.
On Thu, Jan 14, 2021 at 07:18:13PM +0100, Thomas Schwinge wrote:
> libgomp/
> PR libgomp/65099
> * plugin/configfrag.ac (PLUGIN_NVPTX): Restrict to supported
> configurations.
> * configure: Regenerate.
> * plugin/plugin-nvptx.c (nvptx_get_num_devices): Remove 64
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 miss
On Wed, 3 Mar 2021, Richard Biener wrote:
> On Wed, 3 Mar 2021, David Malcolm wrote:
>
> > On Wed, 2021-03-03 at 08:48 +0100, Richard Biener wrote:
> > > On Tue, 2 Mar 2021, Martin Sebor wrote:
> > >
> > > > On 3/2/21 9:52 AM, Jeff Law via Gcc-patches wrote:
> > > > >
> > > > >
> > > > > On 3/
On Thu, Mar 04, 2021 at 09:08:35AM +0100, Richard Biener wrote:
> 2021-03-04 Richard Biener
>
> PR middle-end/97855
> * tree-pretty-print.c: Poison pp_printf.
> (dump_decl_name): Avoid use of pp_printf.
> (dump_block_node): Likewise.
> (dump_generic_node): Likewise
On 3/2/21 6:57 PM, Jason Merrill wrote:
On 3/2/21 5:34 AM, Martin Liška wrote:
On 3/1/21 8:58 PM, Jason Merrill wrote:
On 3/1/21 11:59 AM, Martin Liška wrote:
On 3/1/21 5:36 PM, Jason Merrill wrote:
On 3/1/21 7:43 AM, Martin Liška wrote:
On 2/22/21 11:53 PM, Jason Merrill wrote:
The problem
When diagnostic messages use pretty-printer formats like %D or %E
the pp_printf invocation can end up in tree pretty-printers which
then have to avoid using pp_printf themselves since this function
is not re-entrant.
The following removes all pp_printf uses from tree-pretty-print.c
fixing the obse
65 matches
Mail list logo
