Ping...
On 10/27/19 9:14 AM, Bernd Edlinger wrote:
> Ping...
>
> I'd like to ping for this patch:
> https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01459.html
>
>
> Thanks
> Bernd.
>
> On 10/20/19 9:58 PM, Bernd Edlinger wrote:
>> Hi,
>>
>> this fixes an issue with the gdb step-over aka. "n" com
Changlogs
gcc
--
2019-11-02 Kamlesh Kumar
PR c++/91979 - mangling nullptr expression
* mangle.c (write_template_arg_literal): Handle nullptr
mangling.
* testsuite/g++.dg/cpp0x/nullptr27.C: Modify Test.
* testsuite/g++.dg/cpp0x/pr91979.C: New Test.
li
Hi!
On Wed, Oct 16, 2019 at 09:47:41AM -0400, Michael Meissner wrote:
> This patch fixes the stack protection insns to support stacks larger than
> 16-bits on the 'future' system using prefixed loads and stores.
> +;; We can't use the prefixed attribute here because there are two memory
> +;; ins
On 11/1/19 5:19 PM, Jakub Jelinek wrote:
On Fri, Nov 01, 2019 at 09:56:44PM +0100, Jakub Jelinek wrote:
Ah, used 8.x to test it. There have been r265787 and r269775 changes in
between.
Though
auto d = [] () mutable __attribute__((noreturn)) constexpr {};
auto e = [] () mutable [[noreturn]
Hi!
Apparently my recent change broke quite a lot of setups where people were
configuring --enable-offload-targets= without having the corresponding
offloading compiler already installed.
The following patch simplifies it by removing the need to have it installed
again for compiler building (it is
Hi!
The following patch implements one sentence from the OpenMP 5
standard:
"A context selector that is a strict subset of another context selector
has a score of zero."
I have scoring mostly written too, but haven't added testcases yet, so that
will be in a follow-up patch.
Bootstrapped/regteste
On Fri, Nov 01, 2019 at 03:09:39PM -0600, Martin Sebor wrote:
> * gcc.dg/pr36902.c: Remove xfail.
> --- a/gcc/testsuite/gcc.dg/pr36902.c
> +++ b/gcc/testsuite/gcc.dg/pr36902.c
> @@ -44,7 +44,7 @@ foo2(unsigned char * to, const unsigned char * from, int n)
>*to = *from;
>break
On Fri, Nov 1, 2019 at 7:03 AM Anton Youdkevitch
wrote:
>
> Hello,
>
> Here is the one-liner that fixes the incorrect
> vec_perm cost for thunderx2t99 chip.
> With the patch applied 526.blender of CPU2017
> gets ~5% improvement with no measurable changes
> for other benchmarks.
>
> Bootstrapped OK
On Tue, Oct 29, 2019 at 01:16:53PM +0800, Kewen.Lin wrote:
> (vcond_mask_): New expand.
Say for which mode please? Like
(vcond_mask_ for VEC_I and VEC_I): New expand.
> (vcond_mask_): Likewise.
"for VEC_I and VEC_F", here, but the actual names in the pattern are for
vector m
Hi all,
The attached patch provides frontend and runtime modifications to allow the
subject format specifiers. These are allowed as default behavior and under
-std=f2018.
It does not implement the ew.de0 specifier. I decided to do that part
separarately since it involves different places in
On 10/25/19 11:02 AM, Delia Burduv wrote:
> Hello Jeff,
>
> Yes, it is a backport to gcc-8. No, I don't have commit access. Could
> you please commit it for me?
Done.
Thanks for your patience.
jeff
On 10/24/19 2:56 PM, Jozef Lawrynowicz wrote:
> I added support for reduced code size printf and puts functions to Newlib for
> MSP430 a while ago [1]. By removing support for reentrancy, streams and
> buffering we can greatly reduce code size, which is always often a limitation
> when using printf
On 10/30/19 9:01 AM, Martin Liška wrote:
> Hi.
>
> There's a small code refactoring.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
> Thanks,
> Martin
>
>
> 0001-Come-up-with-ggc_delete.patch
>
> From dc92c8c3e31887b23ef419bc60e3c1607d0e9
On 11/1/19 4:53 AM, Jozef Lawrynowicz wrote:
> Each different MSP430 MCU has two properties that affect code generation,
> which
> are the the CPU ISA and the hardware multiply support. These can be manually
> specified with the -mcpu= and -mhwmult= options, respectively.
> The existing -mmcu= opt
On 10/31/19 10:01 AM, Martin Liška wrote:
> Hi.
>
> operand_equal_p can properly handle situation where we have a CONSTRUCTOR
> where indices are NULL:
>
> if (!operand_equal_p (c0->value, c1->value, flags)
> /* In GIMPLE the indexes can be either NULL or matching i.
>
On Fri, Nov 01, 2019 at 09:56:44PM +0100, Jakub Jelinek wrote:
> Ah, used 8.x to test it. There have been r265787 and r269775 changes in
> between.
> Though
> auto d = [] () mutable __attribute__((noreturn)) constexpr {};
> auto e = [] () mutable [[noreturn]] constexpr {};
> is still accepted.
On 10/31/19 2:06 PM, kamlesh kumar wrote:
Jason,
Can you please review this,
let me know how can we handle -fabi-version?
We should bump latest_abi_version in c-opts.c and use
abi_version_at_least to control this change.
On Wed, Oct 23, 2019 at 7:55 AM Kamlesh Kumar wrote:
---
gcc/cp/m
On 10/31/19 12:54 PM, Jeff Law wrote:
On 10/11/19 10:34 AM, Martin Sebor wrote:
I've fixed the bug in the attached patch. The rest can be suppressed
by replacing the zero-length arrays with flexible array members but
that's just trading one misuse for another. If the code can't be
changed to a
On 11/1/19 4:42 PM, Marek Polacek wrote:
On Fri, Nov 01, 2019 at 04:37:15PM -0400, Jason Merrill wrote:
On 10/22/19 10:53 AM, Marek Polacek wrote:
This patch implements C++20 P0960R3: Parenthesized initialization of aggregates
(; see R0 for more background info). Essentially, if you have
an ag
On Fri, Nov 01, 2019 at 04:42:45PM -0400, Jason Merrill wrote:
> It isn't accepted for me:
>
> wa3.C: In function 'void foo()':
> wa3.C:4:29: warning: attribute ignored [-Wattributes]
> 4 | auto a = [] () [[noreturn]] constexpr {};
> | ^
> wa3.C:4:29: note:
On 11/1/19 3:57 PM, Jakub Jelinek wrote:
On Fri, Nov 01, 2019 at 03:42:58PM -0400, Jason Merrill wrote:
+ for (size_t n = cp_parser_skip_balanced_tokens (parser, 1); ; n++)
+ {
+ size_t after = cp_parser_skip_attributes_opt (parser, n);
+ if (after > n)
On Fri, Nov 01, 2019 at 04:37:15PM -0400, Jason Merrill wrote:
> On 10/22/19 10:53 AM, Marek Polacek wrote:
> > This patch implements C++20 P0960R3: Parenthesized initialization of
> > aggregates
> > (; see R0 for more background info). Essentially, if you
> > have
> > an aggregate, you can now
On 10/22/19 10:53 AM, Marek Polacek wrote:
This patch implements C++20 P0960R3: Parenthesized initialization of aggregates
(; see R0 for more background info). Essentially, if you have
an aggregate, you can now initialize it by (x, y), similarly to {x, y}. E.g.
struct A {
int x, y;
Using -mno-fdiv gives linker errors unless we build the missing divide
routines in libgcc always. There is at least one university project
designing RISC-V parts without FP divide that wants to use the option.
Tested by hand with single-float and double-float builds to verify that
the -mno-fdiv o
On Sat, Oct 19, 2019 at 6:35 PM Jakub Jelinek wrote:
>
> Hi!
>
> On Sat, Oct 19, 2019 at 12:46:56AM -0400, Jason Merrill wrote:
> > gcc/testsuite/g++.dg/cpp2a
> > * nodiscard-construct.C: New test.
> > * nodiscard-once.C: New test.
> > * nodiscard-reason-non
On Fri, Nov 01, 2019 at 03:42:58PM -0400, Jason Merrill wrote:
> > + for (size_t n = cp_parser_skip_balanced_tokens (parser, 1); ; n++)
> > + {
> > + size_t after = cp_parser_skip_attributes_opt (parser, n);
> > + if (after > n)
> > + {
> > + n = afte
On 11/1/19 10:06 AM, Paolo Carlini wrote:
Hi again,
On 31/10/19 16:56, Paolo Carlini wrote:
Hi,
yesterday I noticed that we want to forward the location parameter of
cp_build_binary_op to composite_pointer_type and then
composite_pointer_error. Note, for the time being at least, this is
alw
On 10/31/19 1:21 PM, Jakub Jelinek wrote:
On Wed, Oct 30, 2019 at 05:06:00PM -0400, Jason Merrill wrote:
build_cplus_new does the magic of replacing a dummy argument, e.g.
if (obj_arg && is_dummy_object (obj_arg))
{
call = build_cplus_new (DECL_CONTEXT (f
On 10/31/19 1:10 PM, Jakub Jelinek wrote:
On Wed, Oct 30, 2019 at 11:05:29PM +0100, Jakub Jelinek wrote:
Looks like there used to be a TREE_CALLS_NEW flag in TREE_LANG_FLAG_1, but
that flag is now free for CALL_EXPR.
I'll try a CALL_EXPR flag first.
TREE_LANG_FLAG_1 is also STMT_IS_FULL_EXPR
Hi,
On Tue, Oct 29 2019, Jakub Jelinek wrote:
> Does this approach look reasonable and is it ok with the backend maintainers
> listed in To:? Martin listed for HSA, I'm afraid right now not really sure
> at which point it would be possible to distinguish hsa guarded targeted code
> from host targ
On Thu, 31 Oct 2019, Xiong Hu Luo wrote:
> +@code{-finline} enables inlining of function declared \"inline\".
> +@code{-finline} is enabled at levels -O1, -O2, -O3 and -Os, but not -Og.
Use @option{} to mark up option names (both -finline and all the -O
options in this paragraph). Use @code{} t
On Fri, Nov 01, 2019 at 08:49:58AM +0100, Tobias Burnus wrote:
> On 10/31/19 11:16 PM, Steve Kargl wrote:
>
> > Jeff Law sent me an email … caused a regression for fixed-form
> > source code.
>
> Interesting, what kind of code is used in the real world!
>
Jeff sent me the file from dl_poly that
On Thu, Oct 31, 2019 at 6:33 PM Kugan Vivekanandarajah
wrote:
>
> On Wed, 30 Oct 2019 at 03:11, H.J. Lu wrote:
> >
> > On Sun, Oct 27, 2019 at 6:33 PM Kugan Vivekanandarajah
> > wrote:
> > >
> > > Hi Richard,
> > >
> > > Thanks for the review.
> > >
> > > On Wed, 23 Oct 2019 at 23:07, Richard Bi
On Fri, Nov 01, 2019 at 09:31:07AM -0600, Jeff Law wrote:
> On 11/1/19 9:08 AM, Marek Polacek wrote:
> > On Fri, Nov 01, 2019 at 04:01:12PM +0100, Romain Geissler wrote:
> >> Le mar. 22 oct. 2019 à 14:53, Richard Biener a écrit :
> >>>
> >>> Please make sure to get features intended for GCC 10 fin
On 11/1/19 9:08 AM, Marek Polacek wrote:
> On Fri, Nov 01, 2019 at 04:01:12PM +0100, Romain Geissler wrote:
>> Le mar. 22 oct. 2019 à 14:53, Richard Biener a écrit :
>>>
>>> Please make sure to get features intended for GCC 10 finished
>>> and reviewed before the end of stage 1.
>>>
>>
>> Hi,
>>
>
On Fri, Nov 01, 2019 at 04:01:12PM +0100, Romain Geissler wrote:
> Le mar. 22 oct. 2019 à 14:53, Richard Biener a écrit :
> >
> > Please make sure to get features intended for GCC 10 finished
> > and reviewed before the end of stage 1.
> >
>
> Hi,
>
> I understand my question comes very (most li
Hi,
I have spent some more time looking into PR 70929, how
gimple_check_call_matching_types behaves when LTO-building Firefox to
see what could replace it or if we perhaps could remove it.
TL;DR:
I believe it can and should be removed, possibly except the use in
value-prof.c where I replaced it w
Le mar. 22 oct. 2019 à 14:53, Richard Biener a écrit :
>
> Please make sure to get features intended for GCC 10 finished
> and reviewed before the end of stage 1.
>
Hi,
I understand my question comes very (most likely too) late, but are
there any plans to switch the default C++ dialect to -std=g
Hi again,
On 31/10/19 16:56, Paolo Carlini wrote:
Hi,
yesterday I noticed that we want to forward the location parameter of
cp_build_binary_op to composite_pointer_type and then
composite_pointer_error. Note, for the time being at least, this is
always for CPO_COMPARISON, the other two compo
Hello,
Here is the one-liner that fixes the incorrect
vec_perm cost for thunderx2t99 chip.
With the patch applied 526.blender of CPU2017
gets ~5% improvement with no measurable changes
for other benchmarks.
Bootstrapped OK on aarch64-linux-gnu.
OK for trunk?
2019-11-01 Anton Youdkevitch
In implementing C++20 using enum changes, I wandered into
check_field_decls, and was confused.
This patch makes it better than it was.
*) the main loop showed signs that we used to remove bad fields. but we
don't any more.
*) ... so we can call the field 'field', not 'x'. (still not perfect,
On 11/1/19 1:49 AM, Tobias Burnus wrote:
> On 10/31/19 11:16 PM, Steve Kargl wrote:
>
>> Jeff Law sent me an email … caused a regression for fixed-form
>> source code.
>
> Interesting, what kind of code is used in the real world!
It's from the dl_poly package in Fedora IIRC. It was the only inst
On Okt 31 2019, Richard Sandiford wrote:
> The SVE PCS support broke go, D and Ada because those languages don't
> call TARGET_INIT_BUILTINS. We therefore ended up trying to get the
> TYPE_MAIN_VARIANT of a null __SVBool_t.
>
> We shouldn't really need to apply TYPE_MAIN_VARIANT there anyway,
> s
Each different MSP430 MCU has two properties that affect code generation, which
are the the CPU ISA and the hardware multiply support. These can be manually
specified with the -mcpu= and -mhwmult= options, respectively.
The existing -mmcu= option takes an MCU name as an argument and uses the CPU
IS
On 10.08.2019. 00:15, Joseph Myers wrote:
> On Fri, 9 Aug 2019, Jeff Law wrote:
>
>>> 2019-08-05 Dragan Mladjenovic
>>>
>>> * config.in: Regenerated.
>>> * config/mips/linux.h (NEED_INDICATE_EXEC_STACK): Define to 1
>>> for TARGET_LIBC_GNUSTACK.
>>> * configure: Regenerated.
>>>
On Thu, Oct 31, 2019 at 10:04 PM Steve Kargl
wrote:
>
> On Thu, Oct 31, 2019 at 09:30:26PM +0200, Janne Blomqvist wrote:
> >
> > I'd personally prefer the current behavior. I.e. just let the
> > underlying OS/libc handle it as it sees fit. No need to invent our own
> > semantics here. Tobias quote
"Andre Vieira (lists)" writes:
> Hi,
>
> After my patch I believe the only way orig_loop_vinfo is not null when
> calling vect_analyze_loop is when it is called for an epilogue and in
> that case we no longer use that variable, since
> LOOP_VINFO_ORIG_LOOP_INFO is already set for the epilogue's
On 30/10/2019 13:49, Richard Biener wrote:
>>
>> * expr.c (store_constructor): Add case for constructor of
vectors.
> Why do you need this? The vectorizer already creates such CTORs. Any
> testcase that you can show?
>
> typedef long v2di __attribute__((vector_size(16)));
> v2di
On 10/31/19 11:16 PM, Steve Kargl wrote:
Jeff Law sent me an email … caused a regression for fixed-form
source code.
Interesting, what kind of code is used in the real world!
OK to commit?
OK. Thanks for the patch!
Tobias
2019-10-31 Steven G. Kargl
PR fortran/90988
*
49 matches
Mail list logo
