Hi Kyrill,
Can it be backported to gcc 8/9/10 branches?
Thanks,
-Jiangning
> -Original Message-
> From: Gcc-patches On Behalf Of Kyrylo
> Tkachov
> Sent: Thursday, April 30, 2020 8:27 PM
> To: Kyrylo Tkachov ; Andrew Pinski
> ; Florian Weimer
> Cc: gcc-patches@gcc.gnu.org; nmeye...@amz
On 01/05/2020 11:38, JiangNing OS via Gcc-patches wrote:
> Hi Kyrill,
>
> Can it be backported to gcc 8/9/10 branches?
>
I'm not sure changing the defaults of things like this is a good idea on
'dot' releases.
Having the option is one thing. Changing the default another thing
entirely.
R.
>
In reality, a lot of users are still using old gcc versions running on new
hardware. OpenJDK is a typical example, I think.
> -Original Message-
> From: Richard Earnshaw
> Sent: Friday, May 1, 2020 6:41 PM
> To: JiangNing OS ; Kyrylo Tkachov
> ; Andrew Pinski ; Florian
> Weimer
> Cc: gc
> -Original Message-
> From: Christophe Lyon
> Sent: 30 April 2020 09:51
> To: Kyrylo Tkachov
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: arm: Fix vfp_operand_register for VFP HI regs
>
> On Wed, 29 Apr 2020 at 18:40, Kyrylo Tkachov
> wrote:
> >
> > Hi Christophe,
> >
> > > -Orig
Hi JangNing (please reply inline in the future as that is the preferred style
on this mailing list)
> -Original Message-
> From: JiangNing OS
> Sent: 01 May 2020 11:49
> To: Richard Earnshaw ; Kyrylo Tkachov
> ; Andrew Pinski ; Florian
> Weimer
> Cc: gcc-patches@gcc.gnu.org; nmeye...@am
On 01/05/2020 12:01, Kyrylo Tkachov wrote:
> Hi JangNing (please reply inline in the future as that is the preferred style
> on this mailing list)
>
>> -Original Message-
>> From: JiangNing OS
>> Sent: 01 May 2020 11:49
>> To: Richard Earnshaw ; Kyrylo Tkachov
>> ; Andrew Pinski ; Floria
The deduced return type causes the instantiation of the function body,
which can then require the instantiation of std::projected::operator*
which is intentionally not defined.
This patch uses a helper trait to define the return type, so that the
function body doesn't need to be instantiated. That
Hello world,
because the test case for PR 94788 requires -fsanitize=address to expose
the double free, I have created a subdirectory under gfortran.dg
where such test cases can go.
I have tested this with
make check-fortran RUNTESTFLAGS="asan.exp=*"
and it works; with a compiler that introduce
The libstdc++ manual documents that _T can not be used, because it's a
macro in system headers on some targets.
PR libstdc++/94901
* include/std/type_traits (__is_complete_or_unbounded): Replace
BADNAME _T with _Tp.
* testsuite/17_intro/badnames.cc: New test.
Teste
On Fri, May 01, 2020 at 02:17:54PM +0100, Jonathan Wakely via Gcc-patches wrote:
> The libstdc++ manual documents that _T can not be used, because it's a
> macro in system headers on some targets.
>
> PR libstdc++/94901
> * include/std/type_traits (__is_complete_or_unbounded): Replace
On 01/05/20 13:03 +0100, Jonathan Wakely wrote:
The deduced return type causes the instantiation of the function body,
which can then require the instantiation of std::projected::operator*
which is intentionally not defined.
This patch uses a helper trait to define the return type, so that the
f
On 01/05/20 15:21 +0200, Jakub Jelinek via Libstdc++ wrote:
On Fri, May 01, 2020 at 02:17:54PM +0100, Jonathan Wakely via Gcc-patches wrote:
The libstdc++ manual documents that _T can not be used, because it's a
macro in system headers on some targets.
PR libstdc++/94901
* inclu
On 01/05/20 14:28 +0100, Jonathan Wakely wrote:
On 01/05/20 13:03 +0100, Jonathan Wakely wrote:
The deduced return type causes the instantiation of the function body,
which can then require the instantiation of std::projected::operator*
which is intentionally not defined.
This patch uses a help
On 01/05/20 14:45 +0100, Jonathan Wakely wrote:
On 01/05/20 15:21 +0200, Jakub Jelinek via Libstdc++ wrote:
On Fri, May 01, 2020 at 02:17:54PM +0100, Jonathan Wakely via Gcc-patches wrote:
The libstdc++ manual documents that _T can not be used, because it's a
macro in system headers on some tar
On Mon, Apr 27, 2020 at 04:48:02PM -0500, will schmidt wrote:
> On Mon, 2020-04-27 at 15:48 -0400, Michael Meissner via Gcc-patches
> wrote:
> > Add tests for generating PLI/PADDI with -mcpu=future.
> >
> > This is patch #2 of 7. This patch was run on a little endian power8
> > system
> > running
Hello,
Just a friendly ping on the following patch, hopefully sufficiently
straightforward and tested to be allowed onto branch master.
Thank you!
On Fri, Apr 17, 2020 at 04:49:47PM -0700, Joel Brobecker wrote:
> From: Douglas Rupp
>
> Hello,
>
> (submitting this on behalf of Doug Rupp, one
On Wed, Mar 11, 2020 at 09:12:20AM -0400, Lewis Hyatt via Gcc-patches wrote:
> Great, thank you very much for taking a look at it. Sorry if this
> email is unnecessary noise, but it wasn't quite clear to me whether
> this should also still be approved from a content perspective? I
> didn't want to
Pushed.
Gerald
---
htdocs/projects/cxx-status.html | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/htdocs/projects/cxx-status.html b/htdocs/projects/cxx-status.html
index 40cc4fd6..89e78c01 100644
--- a/htdocs/projects/cxx-status.html
+++ b/htdocs/projects/cxx-status.html
@@ -
Am 27.04.20 um 11:50 schrieb Mark Eggleston:
On 27/04/2020 09:56, Thomas Koenig wrote:
Am 27.04.20 um 09:51 schrieb Mark Eggleston:
Please find attached three slightly different patches based on a
patch for PR59107 originally developed by Janus Weil
and Dominique d'Humieres for
gcc-5. The
On 23.01.20 21:09, Jeff Law wrote:
On Wed, 2020-01-22 at 22:23 +0100, Andreas Tobler wrote:
Hi all,
I'm digginig out old patches and I want to complete the libasan support
for FreeBSD x86_64. The below one was not that obvious when you have
been away for the past years.
In the last import the
This is a missing SFINAE issue when verifying the accessibility of a
static data member.
The reason is that check_accessibility_of_qualified_id unconditionally
passes tf_warning_or_error to perform_or_defer_access_check, even when
called from tsubst_qualified_id(..., complain=tf_none).
This patch
On Fri, 2020-05-01 at 12:52 +0100, Richard Earnshaw wrote:
> On 01/05/2020 12:01, Kyrylo Tkachov wrote:
> > Hi JangNing (please reply inline in the future as that is the preferred
> > style
> > on this mailing list)
> >
> > > -Original Message-
> > > From: JiangNing OS
> > > Sent: 01 May
Hi!
On Mon, Apr 27, 2020 at 05:01:34PM -0500, will schmidt wrote:
> On Mon, 2020-04-27 at 15:53 -0400, Michael Meissner via Gcc-patches wrote:
> > This patch adds a test that verifies that the compiler generates a prefixed
> > load/store instruction where the compiler cannot generate the instructi
GCC maintainers:
The following patch fixes PR94833, vec_first_match_index does not
function as described in its description.
The builtin does not handle vector elements which are zero correctly.
The following patch fixes the issue and adds additional test cases to
verify the vec_first_match_inde
On Thu, 2020-04-23 at 16:05 -0600, Martin Sebor wrote:
> On 4/23/20 9:42 AM, Jeff Law wrote:
> > On Wed, 2020-04-22 at 15:36 -0600, Martin Sebor via Gcc-patches wrote:
> > > When computing the size of an object with a flexible array member
> > > the object size pass doesn't consider that the initia
Within the generic lambda the VLA capture proxy VAR_DECL has DECL_VALUE_EXPR
which is a NOP_EXPR to the VLA type of the proxy. The problem here was that
when instantiating we were tsubsting that type twice, once for the type of
the DECL and once for the type of the NOP_EXPR, and getting two
differ
For default member initializers in templates it's important to push into the
right context during get_nsdmi. But for a local class that's not possible,
and trying leaves the function context we need to be in, so don't try.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeLog
2020-05-0
cp_finish_decl avoids setting TREE_READONLY on TREE_STATIC variables that
have non-constant construction or destruction, but -fmerge-all-constants was
converting an automatic variable to static while leaving TREE_READONLY set.
Fixed by clearing the flag in cp_finish_decl in the presence of
-fmerg
Aggregate-paren-init breaks tuple and optional. This fixes the breakage.
An LWG issue will be filed.
Full suite test run pending. Ok for master and gcc-10 if the full tests pass?
2020-05-01 Ville Voutilainen
PR libstdc++/94890
* include/std/optional (optional(_Up&&)): Add is_aggregate
Hi,
The recent libsanitizer change seems to have had a corrupt
chunk, that caused it to apply a change part way through the
SUBTARGET_INIT_BUILTINS macro, leading to a bootstrap fail
in stage1.
tested on x86_64-darwin16,
applied to master,
thanks
Iain
gcc/ChangeLog:
2020-05-01 Iain Sandoe
Hi all,
FreeBSD does not have the alloca.h header. Do not include it in the test
cases which do include alloca.h.
There are two versions of this patch available, the one attached which
uses ifdef or another one which defines alloca with __builtin_alloca.
I tested both approaches and they wo
On 01.05.20 21:02, Iain Sandoe wrote:
Hi,
The recent libsanitizer change seems to have had a corrupt
chunk, that caused it to apply a change part way through the
SUBTARGET_INIT_BUILTINS macro, leading to a bootstrap fail
in stage1.
tested on x86_64-darwin16,
applied to master,
Sorry for the b
On 5/1/20 11:23 AM, Patrick Palka wrote:
This is a missing SFINAE issue when verifying the accessibility of a
static data member.
The reason is that check_accessibility_of_qualified_id unconditionally
passes tf_warning_or_error to perform_or_defer_access_check, even when
called from tsubst_quali
I think this change is what introduced a glibc testsuite regression in the
localplt test.
https://sourceware.org/pipermail/libc-testresults/2020q2/006097.html
Contents of elf/check-localplt.out:
Extra PLT reference: libc.so: getauxval
A reference to getauxval from libgcc is also a namespace vi
(And the winner for the longest URL is ... Analog Devices.)
Pushed.
Gerald
---
htdocs/readings.html | 1 +
1 file changed, 1 insertion(+)
diff --git a/htdocs/readings.html b/htdocs/readings.html
index 2d0a4275..fde9c13d 100644
--- a/htdocs/readings.html
+++ b/htdocs/readings.html
@@ -95,6 +95,7
On 4/30/20 7:48 PM, Marek Polacek wrote:
On Wed, Apr 29, 2020 at 05:10:44PM -0400, Jason Merrill via Gcc-patches wrote:
On 4/28/20 11:55 PM, Marek Polacek wrote:
Whew, this took a while. We fail to parse "p->template A::a()"
(where p is of type A *) because since r249752 we treat the RHS of th
On 4/30/20 12:03 PM, Marek Polacek wrote:
Here we have (conceptually *) something like
struct B { };
struct D : B { };
D(0); // invalid
and in C++20 the ()-initialization has created a { 0 } constructor that
it tries to initialize an object of type D with. We should reject
initializin
Pushed.
Gerald
---
htdocs/readings.html | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/htdocs/readings.html b/htdocs/readings.html
index fde9c13d..0dd27368 100644
--- a/htdocs/readings.html
+++ b/htdocs/readings.html
@@ -257,7 +257,7 @@ names.
pru
Manufacturer: Texas
On Fri, 2020-05-01 at 09:42 -0700, Carl Love via Gcc-patches wrote:
> GCC maintainers:
>
Hi,
subject: Re: [PATCH] rs6000, fix vec_first_match_index for nulls
^ See if you can include the pr94833 string in the subject somewhere.
> The following patch fixes PR94833, vec_first_match_index doe
On Fri, 2020-05-01 at 10:48 -0500, Segher Boessenkool wrote:
> Hi!
>
> On Mon, Apr 27, 2020 at 05:01:34PM -0500, will schmidt wrote:
> > On Mon, 2020-04-27 at 15:53 -0400, Michael Meissner via Gcc-patches
> > wrote:
> > > This patch adds a test that verifies that the compiler generates
> > > a pr
GCC maintainers:
This is a resend of "[PATCH]rs6000, fix vec_first_match_index for
nulls" from earlier today.
Per the received comments the pr number was added to the subject line.
I also tweaked the message to make it clear that the patch fixed issues
with vectors whose elements contain zeros r
On Fri, May 01, 2020 at 03:54:26PM -0500, will schmidt wrote:
> > The other way around :-) stfs is for single precision float
> > ("float",
> > in C), while stfd is for double precision float ("double", in C).
>
> I came up with my comment based on what was being tested for further
> below. If
On Fri, 1 May 2020 at 21:15, Ville Voutilainen
wrote:
>
> Aggregate-paren-init breaks tuple and optional. This fixes the breakage.
> An LWG issue will be filed.
The previous approach was bogus. Here's a better one. Ok for master
and gcc-10 if
full testsuite run passes?
2020-05-02 Ville Voutilai
On Fri, 2020-05-01 at 17:02 -0500, Segher Boessenkool wrote:
> On Fri, May 01, 2020 at 03:54:26PM -0500, will schmidt wrote:
> > > The other way around :-) stfs is for single precision float
> > > ("float",
> > > in C), while stfd is for double precision float ("double", in C).
> >
> > I came up
The original code in libiberty says "FIXME" and then says it has not been
validated to be ANSI compliant. However, this patch changes the function to
match implementations that ARE compliant, and such code is in the public
domain.
I ran the test results, and there are no test failures.
--- strstr
On Thu, Feb 6, 2020 at 12:01 AM Richard Sandiford
wrote:
>
> "H.J. Lu" writes:
> > On Wed, Feb 5, 2020 at 2:51 PM H.J. Lu wrote:
> >>
> >> On Wed, Feb 5, 2020 at 2:37 PM Marek Polacek wrote:
> >> >
> >> > On Wed, Feb 05, 2020 at 02:24:48PM -0800, H.J. Lu wrote:
> >> > > On Wed, Feb 5, 2020 at 1
Hello,
I'm not sure if this is the right mailing list for this patch but it modifies
the top level directory of binutils-gdb for which I understand GCC to be the
upstream. The purpose of this patch is to use PKG_CHECK_MODULES in
config/debuginfod.m4 since debuginfod supports pkg-config. Otherwi
Uros Bizjak writes:
Ping.
> On Wed, Apr 1, 2020 at 9:28 AM Hongtao Liu wrote:
>>
>> On Wed, Apr 1, 2020 at 3:32 PM Hongtao Liu wrote:
>> >
>> > Hi:
>> > This patch is about to enable GCC support for TSXLDTRK which would
>> > be in GLC. There's only 2 instructions: XRESLDTRK, XSUSLDTRK, more
ping.
> On Wed, Apr 1, 2020 at 9:23 AM Hongtao Liu wrote:
>>
>> Hi:
>> This patch is about to enable GCC support for SERIALIZE which would
>> be in GLC. There's only 1 instruction: SERIALIZE, more details please
>> refer to
>> https://software.intel.com/sites/default/files/managed/c5/15/arch
49 matches
Mail list logo
