On 10/16/20 11:31 AM, Marek Polacek wrote:
In this testcase we weren't able to deduce b's type:
template void Task() { }
auto b = { &Task };
because resolve_nondeduced_context doesn't iterate on the {}'s elements.
So make sure to look into {} too. We don't need to handle nested {}
here.
On Wed, Oct 28, 2020 at 2:53 AM Rainer Orth
wrote:
>
> > This libgo patch by Nikhil Benesch imports additional code from
> > upstream for handing system calls on BSD systems. This makes the
> > syscall package on NetBSD complete enough to compile the standard
> > library. Boostrapped and ran Go
On 10/19/20 8:52 PM, Marek Polacek wrote:
My earlier patch for this PR, r11-86, broke pybind11. That patch
changed cp_parser_class_name to also consider the object expression
scope (parser->context->object_type) to fix parsing of
p->template A::foo(); // consider p's scope too
Here we rejec
Hi!
On Wed, Oct 28, 2020 at 11:13:28AM +, Alex Coplan wrote:
> This fails bootstrap since we trigger -Wsign-compare without the cast to
> unsigned HOST_WIDE_INT on shift_amt:
>
> + else if (GET_CODE (inner) == MULT
> +&& CONST_INT_P (XEXP (inner, 1))
> +&& pos_rtx == 0 && pos
I noticed that declarator->parenthesized is, for this warning, only set
to the opening paren. But we can easily make it a range and generate
a nicer diagnostic. Moreover, we can then offer a fix-it hint.
TL;DR: This patch changes
mvp3.C:8:7: warning: unnecessary parentheses in declaration of ‘i
Ian, are you able to review this? I saw that you reviewed many of the
prior changes to the Rust demangler.
If not, can you suggest someone who can?
Thanks very much.
Nikhil
On 10/28/20 5:22 PM, Nikhil Benesch wrote:
Ian, are you able to review this? I saw that you reviewed many of the
prior changes to the Rust demangler.
If not, can you suggest someone who can?
Thanks very much.
Nikhil
I seem to have failed to convince my email client to set the appropriate
re
On Wed, Oct 28, 2020 at 02:46:36PM -0400, Jason Merrill wrote:
> On 10/28/20 2:00 PM, Marek Polacek wrote:
> > On Tue, Oct 27, 2020 at 01:36:30PM -0400, Jason Merrill wrote:
> > > On 10/24/20 6:52 PM, Marek Polacek wrote:
> > > > Here, in r11-155, I changed the call to uses_template_parms to
> > >
On 10/28/20 5:29 PM, Marek Polacek wrote:
On Wed, Oct 28, 2020 at 02:46:36PM -0400, Jason Merrill wrote:
On 10/28/20 2:00 PM, Marek Polacek wrote:
On Tue, Oct 27, 2020 at 01:36:30PM -0400, Jason Merrill wrote:
On 10/24/20 6:52 PM, Marek Polacek wrote:
Here, in r11-155, I changed the call to u
FWIW, the patch has become slightly outdated compared to the Rust upstream, so
if someone wants to review it I should prepare a new version.
The changes would be for the MVP version of "const generics" (Rust's equivalent
to C++ templates with value parameters, enabling e.g. types like
`CustomAr
On 10/28/20 5:14 PM, Marek Polacek wrote:
I noticed that declarator->parenthesized is, for this warning, only set
to the opening paren. But we can easily make it a range and generate
a nicer diagnostic. Moreover, we can then offer a fix-it hint.
TL;DR: This patch changes
mvp3.C:8:7: warning:
Hi Mike,
On Thu, Oct 22, 2020 at 06:10:37PM -0400, Michael Meissner wrote:
> PowerPC: Use __builtin_pack_ieee128 if long double is IEEE 128-bit.
This title makes no sense, and thankfully is not what the patch does :-)
> This patch changes the __ibm128 emulator to use __builtin_pack_ieee128
> ins
I think it is mostly a matter of snagging some of Ian's limited time.
I suspect it is still worthwhile to try to get the original patch
reviewed and merged, because then any follow-up changes for const
generics support will be smaller and easier to review.
On Wed, Oct 28, 2020 at 5:48 PM Eduard-Mi
On Wed, Oct 28, 2020 at 12:16:00PM -0500, Segher Boessenkool wrote:
> On Wed, Oct 28, 2020 at 09:20:56PM +1030, Alan Modra wrote:
> > Otherwise some versions of dejagnu go ahead and run the vsx tests
> > below when they should not. To best cope with older dejagnu, put
> > "run" before "compile", t
On Wed, Oct 28, 2020 at 3:22 PM Nikhil Benesch via Gcc-patches
wrote:
>
> I think it is mostly a matter of snagging some of Ian's limited time.
> I suspect it is still worthwhile to try to get the original patch
> reviewed and merged, because then any follow-up changes for const
> generics support
David:
On Sat, 2020-10-24 at 11:29 -0400, David Edelsohn wrote:
> Hi, Carl
>
> Not commenting on the implementation.
>
> Please stop using powerpc*-*-* in the test cases. The test cases
> already are in the gcc.target/powerpc directory.
>
> Do the test cases really need lp64, or should this re
C2x has changed the expansions of the true and false macros in
so that they have type _Bool (including in #if conditions,
i.e. an unsigned type in that context). Use the new expansions in
GCC's for C2x.
See bug 82272 for related discussion (but this patch does *not*
implement the warning discus
On Thu, Oct 22, 2020 at 06:09:38PM -0400, Michael Meissner wrote:
> This patch adds long double variants of the power10 __float128 built-in
> functions. This is needed when long double uses IEEE 128-bit because
> __float128 uses TFmode in this case instead of KFmode. If this patch is not
> applie
On Wed, Oct 28, 2020 at 01:44:54PM -0500, Segher Boessenkool wrote:
> On Wed, Oct 28, 2020 at 09:18:35PM +1030, Alan Modra wrote:
> > >From e7ce33cef478a826a2fe4e110b43b49586ef2438 Mon Sep 17 00:00:00 2001
> > From: Alan Modra
> > Date: Wed, 28 Oct 2020 15:57:57 +1030
> > Subject:
> >
> > I noti
On Wed, Oct 28, 2020 at 03:09:08PM -0400, Jason Merrill wrote:
> On 10/28/20 1:58 PM, Marek Polacek wrote:
> > On Wed, Oct 28, 2020 at 01:26:53AM -0400, Jason Merrill via Gcc-patches
> > wrote:
> > > On 10/24/20 7:40 PM, Marek Polacek wrote:
> > > > On Fri, Oct 23, 2020 at 09:33:38PM -0400, Jason
Hi Ian,
Thanks for replying! (Also I'm really sorry for the missing hard wrapping
in my earlier email, I shouldn't have sent that from my phone)
Regarding this being a blocker: we've already made the changes to Rust, and
the new ("v0") mangling format continues to remain opt-in and nightly-only,
Hi,
This is the 5th version of the implementation of patch -fzero-call-used-regs.
The major change compared to the previous version (4th version) are:
1. Documentation change per Richard’s suggestion;
2. Use namespace for zero_regs_code;
3. Add more general testing cases per Richard’s suggestio
We have only riscv64 asan support, there is no riscv32 support as yet. So I
need to be able to conditionally enable asan support for the riscv target. I
implemented this by returning zero from the asan_shadow_offset function. This
requires a change to toplev.c and docs in target.def.
The asan s
On 26/10/20 21:09 +, Jonathan Wakely wrote:
On 26/10/20 13:47 -0700, Thomas Rodgers wrote:
From: Thomas Rodgers
New ctors and ::view() accessor for -
* basic_stingbuf
* basic_istringstream
* basic_ostringstream
* basic_stringstreamm
New ::get_allocator() accessor for basic_stringbuf.
lib
On Thu, Oct 22, 2020 at 06:06:03PM -0400, Michael Meissner wrote:
> This patch adds the various decimal to/from IEEE 128-bit conversions. I
> had to make some changes to the infrastructure, since that infrastructure
> assumed that there is a sprintf/scanf format modifier to convert floating
> poin
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to master as 0a36f5f21cd9dcaaf99e78d2ec995d6cb2918274.
gcc/analyzer/ChangeLog:
* program-state.cc (sm_state_map::print): Guard the printing of
the origin pointer with !flag_dump_noaddr.
* region.cc (strin
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to master as e9751143e237b507a81234a573a200ea45e7111a.
gcc/ChangeLog:
* Makefile.in (ANALYZER_OBJS): Add analyzer/complexity.o.
gcc/analyzer/ChangeLog:
* analyzer.h (class state_machine): New forward decl.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to master as r11-4510-g1a9af271275f4893e28c789c8f1964025694eda1.
gcc/analyzer/ChangeLog:
PR analyzer/97608
* region-model-reachability.cc (reachable_regions::handle_sval):
Operands of reachable reversible
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to master as f635f0ce87d687b177b734968f18226d50499e75.
gcc/analyzer/ChangeLog:
* program-state.cc (sm_state_map::on_liveness_change): Sort the
leaking svalues before calling on_state_leak.
(program_state:
PowerPC: PR libgcc/97543, fix 64-bit long double issues
There are two issues in PR libgcc/97543 which shows up if you build a GCC
compiler with long double defaulting to 64-bit instead of 128-bit with IBM
extended double:
1) The first issue was the t-linux file forced the entire libgcc libra
On Wed, Oct 28, 2020 at 7:21 PM Carl Love wrote:
>
> David:
>
> On Sat, 2020-10-24 at 11:29 -0400, David Edelsohn wrote:
> > Hi, Carl
> >
> > Not commenting on the implementation.
> >
> > Please stop using powerpc*-*-* in the test cases. The test cases
> > already are in the gcc.target/powerpc di
Please withdraw from consideration the patch that turned on -mno-gnu-attribute
for just the ibm-ldouble.o module in favor of the patch for PR libgcc/97543
that I just posted:
PR libgcc/97543 patch:
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/557413.html
Withdrawn patch:
https://
On Thu, Oct 29, 2020 at 2:46 AM Richard Sandiford
wrote:
>
> Hongtao Liu writes:
> > On Tue, Oct 27, 2020 at 7:13 PM Richard Sandiford
> > wrote:
> >>
> >> Hongtao Liu via Gcc-patches writes:
> >> > Hi:
> >> > For inline asm, there could be an operand like (not (mem:)), it's
> >> > not a vali
This libgo patch by Nikhil Benesch adds support for NetBSD versioned
symbols. On NetBSD, for backwards compatibility, various libc symbols
are renamed to a symbol with a version suffix. For example, this is
the (abbreviated) definition of sigaction:
int sigaction(...) __asm__ ("__sigaction14"
On 28/10/20 23:59 +, Jonathan Wakely wrote:
On 26/10/20 21:09 +, Jonathan Wakely wrote:
On 26/10/20 13:47 -0700, Thomas Rodgers wrote:
From: Thomas Rodgers
New ctors and ::view() accessor for -
* basic_stingbuf
* basic_istringstream
* basic_ostringstream
* basic_stringstreamm
New ::g
On Wed, Oct 28, 2020 at 8:24 PM Uros Bizjak wrote:
>
> On Wed, Oct 28, 2020 at 10:54 AM Hongyu Wang wrote:
> >
> > Hi Uros,
> >
> > Thanks for the example. We've update the patterns with new expanders
> > and predicates like vzeroall.
> > Now the generated insn for "encodekey128u32" is like
> >
The ranger currently handles "inferred" non-nulls with a special cache..
inferred ranges are thing like
a_2 = *b_1
the dereference of b_1 implies that any use of b_1 after that statement
is non-null (or a trap would have happened). The problem is that most
ranges are calculated as a result
Of course, one needs the patch...
On 10/28/20 10:04 PM, Andrew MacLeod wrote:
The ranger currently handles "inferred" non-nulls with a special cache..
inferred ranges are thing like
a_2 = *b_1
the dereference of b_1 implies that any use of b_1 after that
statement is non-null (or a trap wou
On Wed, Oct 28, 2020 at 05:48:08PM -0400, Jason Merrill wrote:
> On 10/28/20 5:29 PM, Marek Polacek wrote:
> > On Wed, Oct 28, 2020 at 02:46:36PM -0400, Jason Merrill wrote:
> > > On 10/28/20 2:00 PM, Marek Polacek wrote:
> > > > On Tue, Oct 27, 2020 at 01:36:30PM -0400, Jason Merrill wrote:
> > >
On Wed, Oct 28, 2020 at 02:43:30PM -0400, Jason Merrill wrote:
> On 10/28/20 2:01 PM, Marek Polacek wrote:
> > I noticed that C++20 P1120R0 deprecated certain arithmetic conversions
> > as outlined in [depr.arith.conv.enum], but we don't warn about them. In
> > particular, "If one operand is of en
On Wed, Oct 28, 2020 at 02:34:15PM -0400, Jason Merrill via Gcc-patches wrote:
> On 10/28/20 2:02 PM, Marek Polacek wrote:
> > This patch implements CWG 625 which prohibits using auto in a template
> > argument. A few tests used this construction. We could perhaps only
> > give an error in C++20,
On 10/27/20 2:38 PM, Liu Hao via Gcc-patches wrote:
在 2020/10/8 22:56, Jason Merrill 写道:
Hmm, why isn't the mingw implementation used for all programs? That would
avoid the bug.
There was a little further discussion about this [1].
TL;DR: The mingw-w64 function is linked statically and su
On Wed, Oct 28, 2020 at 7:28 PM Alan Modra wrote:
>
> On Wed, Oct 28, 2020 at 01:44:54PM -0500, Segher Boessenkool wrote:
> > On Wed, Oct 28, 2020 at 09:18:35PM +1030, Alan Modra wrote:
> > > >From e7ce33cef478a826a2fe4e110b43b49586ef2438 Mon Sep 17 00:00:00 2001
> > > From: Alan Modra
> > > Date
On Wed, Oct 28, 2020 at 7:53 PM Eduard-Mihai Burtescu wrote:
> I agree that landing the extra changes later on top should be fine anyway,
> though when I make the sprintf -> snprintf change, I could provide the extra
> changes as well (either as a combined patch, or as a second tiny patch).
>
> Sa
On Wed, Oct 28, 2020 at 11:35:07PM -0400, David Edelsohn wrote:
> Alan,
>
> It is disrespectful for you to ignore the review of a maintainer and
> your colleague. You may not pick and choose amongst maintainers. And
> Segher should not be so disrespectful as to contradict his colleague
> and co-
On Tue, Oct 27, 2020 at 7:13 PM Richard Sandiford
wrote:
>
> Hongtao Liu via Gcc-patches writes:
> > Hi:
> > For inline asm, there could be an operand like (not (mem:)), it's
> > not a valid operand for normal memory constraint.
> > Bootstrap is ok, regression test is ok for make check
> > RU
Hi Uros,
> is there a reason to introduce all these (with corresponding changes)?
> SSE options live in ISA bitmap, so it is kind of strange you need to
> handle them in ISA2 bitmap. Option handling is not exactly my area,
> please ask HJ to comment and review this part.
As Hongtao said, this par
101 - 147 of 147 matches
Mail list logo
