It's been 32 ever since the CRIS port was committed.
A TODO-item of mine has been to check whether the
non-default setting of MAX_FIXED_MODE_SIZE makes sense
wrt. performance and/or code-size with a modern gcc. It
doesn't, so it goes. The setting is now the default,
GET_MODE_BITSIZE (DImode)
See comment.
* gcc.target/cris/pr93372-1.c: Adjust expected assembler result
to allow an eliminated stack-frame.
---
gcc/testsuite/gcc.target/cris/pr93372-1.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.target/cris/pr93372-1.c
This introduced an ICE building glibc for i686.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99422
https://sourceware.org/pipermail/libc-testresults/2021q1/007615.html
--
Joseph S. Myers
jos...@codesourcery.com
This is an ICE on invalid where we crash because since r269032 we
keep error_mark_node around instead of using noexcept_false_spec
when things go wrong; see the walk_field_subobs hunk.
We crash in deduce_inheriting_ctor which calls synthesized_method_walk
to deduce the exception-specification,
On Fri, 5 Mar 2021, Jason Merrill wrote:
> On 3/5/21 1:05 PM, Patrick Palka wrote:
> > Here, during cxx_eval_increment_expression (with lval=false) of
> > ++__first where __first is &"mystr"[0], we correctly update __first
> > to &"mystr"[1] but we end up returning &"mystr"[0] + 1 instead of
> >
On 3/3/21 7:55 PM, Marek Polacek wrote:
In this test we are building a call in a template, but since neither
the function nor any of its arguments are dependent, we go down the
normal path in finish_call_expr. convert_arguments sees that we're
binding a reference to int to double and therein
Nested functions are permitted for C but not C++ as extension.
They are also permitted for Fortran, which generates DECL_CONTEXT
== NAMESPACE_DECL for module variables.
That causes the gcc_assert (decl_function_context (decl) == info->context)
to fail in tree-nested.c's lookup_field_for_decl.
On 3/5/21 3:44 PM, Jakub Jelinek wrote:
On Wed, Feb 24, 2021 at 07:08:34PM -0500, Jason Merrill via Gcc-patches wrote:
gcc/ChangeLog:
PR c++/96078
* cgraphunit.c (process_function_and_variable_attributes): Don't
warn about flatten on an alias if the target also has it.
On 3/4/21 9:37 PM, Marek Polacek wrote:
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
On 3/4/21 6:19 PM, Marek Polacek wrote:
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
On 3/5/21 11:44 AM, Marek Polacek wrote:
We crash here, because in a template, an enumerator doesn't have
a type until we've called finish_enum_value_list. But our -Wshadow
implementation, check_local_shadow, is called when we pushdecl in
build_enumerator, which takes place before
On 3/5/21 1:04 PM, Patrick Palka wrote:
This makes tsubst_copy appropriately handle a variable template-id, which
in turn fixes tsubsting a COMPONENT_REF whose member operand is known at
parse time to be a variable template-id, as in the initialization of 'x'
in the first testcase. Previously,
On 3/5/21 1:05 PM, Patrick Palka wrote:
Here, during cxx_eval_increment_expression (with lval=false) of
++__first where __first is &"mystr"[0], we correctly update __first
to &"mystr"[1] but we end up returning &"mystr"[0] + 1 instead of
&"mystr"[1]. This unreduced return value inhibits other
On 3/5/21 3:42 PM, Patrick Palka wrote:
On Fri, 5 Mar 2021, Jason Merrill wrote:
On 3/4/21 9:55 PM, Patrick Palka wrote:
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:
Hi!
When performing cfg cleanup at the end of cfg pass, if there are any OpenMP
regions and some basic blocks are unreachable and contain forced labels,
remove_bb moves the labels to previous bb, but if the two bb belong to different
OpenMP regions, that means it will end up in a different
Header units can declare the same entity, and this can lead to one of
them containing a (non-using) binding to an import. If one gets the
cluster ordering just right, an assert will trigger. Relax that assert.
PR c++/99245
gcc/cp/
* module.cc
Hi!
As I wrote in the mail with the previous PR99321 fix, we have various
bugs where we emit instructions that need avx512bw and avx512vl
ISAs when compiling with -mavx512vl -mno-avx512bw.
Without the following patch,
/* PR target/99321 */
/* Would need some effective target for GNU as that
On Wed, Feb 24, 2021 at 07:08:34PM -0500, Jason Merrill via Gcc-patches wrote:
> gcc/ChangeLog:
>
> PR c++/96078
> * cgraphunit.c (process_function_and_variable_attributes): Don't
> warn about flatten on an alias if the target also has it.
> * cgraph.h
On Fri, 5 Mar 2021, Jason Merrill wrote:
> On 3/4/21 9:55 PM, Patrick Palka wrote:
> > 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 Fri, Mar 05, 2021 at 04:19:47PM +, Iain Sandoe wrote:
> Jakub Jelinek via Gcc-patches wrote:
>
> > As reported, bootstrap currently fails on older Darwin because
> > MAP_ANONYMOUS
> > is not defined.
> >
> > The following is what gcc/system.h does, so I think it should work for
> >
Hi!
The following testcase shows that while we nicely optimize away the
useless and? of shift count before rotation for [SD]Imode rotates,
we don't do that for [QH]Imode.
The following patch optimizes that by using the right iterator on those
4 patterns.
Bootstrapped/regtested on x86_64-linux
Hi!
As can be seen on:
#include
unsigned char f1 (unsigned char x, int y) { return std::rotl (x, y); }
unsigned char f2 (unsigned char x, int y) { return std::rotr (x, y); }
unsigned short f3 (unsigned short x, int y) { return std::rotl (x, y); }
unsigned short f4 (unsigned short x, int y) {
Dear all,
I finally figured out that the array dimensions simply need to be
large enough to get invalid memory accesses that actual lead to a
crash.
I will commit the following testcase along with the fix to libfortran:
! { dg-do run }
! PR libfortran/99218 - matmul on temporary array accesses
This turned out to be the function version of the previous fix. We can
import an implicit specialization declaration that we need to
instantiate. We must mark the instantiation so we remember to stream it.
PR c++/99377
gcc/cp/
* pt.c (instantiate_decl): Call
On 3/4/21 9:55 PM, Patrick Palka wrote:
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
ints can be used as futex on Linux. ptrdiff_t on 64-bit Linux can't.
libstdc++-v3/ChangeLog:
* include/std/latch: Use int instead of ptrdiff_t
---
libstdc++-v3/include/std/latch | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libstdc++-v3/include/std/latch
Our thread's ID does not change so we don't have to get it every time
and hash it every time.
libstdc++-v3/ChangeLog:
* include/std/barrier(arrive): move hasher one level up in the
stack.
---
libstdc++-v3/include/std/barrier | 10 +-
1 file changed, 5 insertions(+), 5
Discussion at:
https://gcc.gnu.org/pipermail/libstdc++/2021-February/052043.html
This patch set includes the uncontroversial parts that improve
performance but don't otherwise change ABI.
Please note we still need to decide on how to deal with the future ABI
break.
Thiago Macieira (3):
Atomic
The kernel doesn't care what we store in those 32 bits, only that they are
comparable. This commit adds:
* pointers and long on 32-bit architectures
* unsigned
* untyped enums and typed enums on int & unsigned int
* float
We're not using FUTEX_OP anywhere today. The kernel reserves 4 bits for
Here, during cxx_eval_increment_expression (with lval=false) of
++__first where __first is &"mystr"[0], we correctly update __first
to &"mystr"[1] but we end up returning &"mystr"[0] + 1 instead of
&"mystr"[1]. This unreduced return value inhibits other pointer
arithmetic folding during later
This makes tsubst_copy appropriately handle a variable template-id, which
in turn fixes tsubsting a COMPONENT_REF whose member operand is known at
parse time to be a variable template-id, as in the initialization of 'x'
in the first testcase. Previously, we rejected this testcase with the
error
On Fri, Mar 05, 2021 at 06:00:04PM +0100, Eric Botcazou wrote:
> > Here, when substituting still-dependent args into an alias template, we see
> > a non-const type because the default argument is non-const, and is not a
> > template parm object because it's still dependent.
> >
> > Tested
Nathan Sidwell wrote:
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
> Here, when substituting still-dependent args into an alias template, we see
> a non-const type because the default argument is non-const, and is not a
> template parm object because it's still dependent.
>
> Tested x86_64-pc-linux-gnu, applying to trunk.
>
> gcc/cp/ChangeLog:
>
> PR
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99378
The patch was successfully bootstrapped and tested on x86-64.
commit e786c7547eda4edd90797f6cae0f5e6405d64773 (HEAD -> master)
Author: Vladimir N. Makarov
Date: Fri Mar 5 11:41:25 2021 -0500
[PR99378]
We crash here, because in a template, an enumerator doesn't have
a type until we've called finish_enum_value_list. But our -Wshadow
implementation, check_local_shadow, is called when we pushdecl in
build_enumerator, which takes place before finish_enum_value_list.
Bootstrapped/regtested on
Jakub Jelinek via Gcc-patches wrote:
As reported, bootstrap currently fails on older Darwin because
MAP_ANONYMOUS
is not defined.
The following is what gcc/system.h does, so I think it should work for
libgcov.
Build tested on x86_64-linux, ok for trunk?
bootstrap suceeded r11-7524 + this
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
which has some
On 05/03/2021 14:18, David Malcolm wrote:
> On Fri, 2021-03-05 at 10:58 +, Philip Herron wrote:
>> On 04/03/2021 16:45, David Malcolm wrote:
>>> On Thu, 2021-03-04 at 16:17 +, Philip Herron wrote:
In development of the Rust FE logging is useful in debugging.
Instead
of
Hi,
this patch fixes the last bit of PR 99122 where various bits of IPA
infrastructure are presented with a program with type mismatches that
make it have undefined behavior, and when inlining or performing
IPA-CP, and encountering such mismatch, we basically try to
VIEW_CONVERT_EXPR whatever the
Hi,
We discovered an issue with the GNAT implementation of the hashed container
types.
The RM states (A.18-4-18/2, A.18.7-17/2, et al) that "the predefined "="
operator for type Cursor returns True if both cursors are No_Element, or
designate the same element in the same container."
In
On Fri, 2021-03-05 at 10:58 +, Philip Herron wrote:
> On 04/03/2021 16:45, David Malcolm wrote:
> > 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
Hi!
As reported, bootstrap currently fails on older Darwin because MAP_ANONYMOUS
is not defined.
The following is what gcc/system.h does, so I think it should work for
libgcov.
Build tested on x86_64-linux, ok for trunk?
2021-03-05 Jakub Jelinek
PR gcov-profile/99406
*
When an incomplete class specialization is imported, and is completed by
instantiation, we were failing to mark the instantiation, and thus
didn't stream it out. Leading to errors in importing as we had members
of an incomplete type.
PR c++/99389
gcc/cp/
* pt.c
This fixes the build breakage introduced by the latest glibc release.
Tested on x86-64/Linux, applied on mainline, 10 and 9 branches.
2021-03-05 Eric Botcazou
PR ada/99264
* init.c (__gnat_alternate_sta) [Linux]: Remove preprocessor test on
MINSIGSTKSZ and bump size
On 04/03/2021 16:45, David Malcolm wrote:
> 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
On Mon, 8 Feb 2021 at 18:10, Kyrylo Tkachov via Gcc-patches
wrote:
>
>
>
> > -Original Message-
> > From: Andre Vieira (lists)
> > Sent: 03 February 2021 17:59
> > To: gcc-patches@gcc.gnu.org
> > Cc: Kyrylo Tkachov
> > Subject: [AArch64] Fix vector multiplication costs
> >
> > This
On Thu, Mar 4, 2021 at 7:28 PM Eric Botcazou wrote:
>
> 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?
OK.
>
> 2021-03-04 Eric Botcazou
>
> PR rtl-optimization/99376
>
Hi!
Aarch64, ARM and a couple of other architectures have 16-bit floats, HFmode.
As can be seen e.g. on
void
foo (void)
{
__fp16 a = 1.0;
asm ("nop");
a = 2.0;
asm ("nop");
a = 3.0;
asm ("nop");
}
testcase, GCC mishandles this on the dwarf2out.c side by assuming all
floating point
49 matches
Mail list logo
