On Tue, 28 May 2019, Martin Sebor wrote:
> On 5/24/19 9:49 AM, Alex Henrie wrote:
> > On Fri, May 24, 2019 at 2:01 AM Richard Biener wrote:
> > >
> > > I'm not sure we really need a new warning for this.
> >
> > On Fri, May 24, 2019 at 9:23 AM Martin Sebor wrote:
> > >
> > > I don't think GCC
On 5/28/19 10:31 PM, Christophe Lyon wrote:
> Was it your intention?
Hi.
No ;) fixed as r271729.
Thanks for reporting,
Martin
Hi.
It's an obvious error that I've just tested on ppc64le.
I'm going to install the patch.
Martin
gcc/testsuite/ChangeLog:
2019-05-29 Martin Liska
PR testsuite/90657
* gcc.dg/ipa/pr90555.c: Remove duplicate dg-compile.
---
gcc/testsuite/gcc.dg/ipa/pr90555.c | 3 +--
1 file
Hi,
Please go ahead and review this. In the test case
gcc.target/powerpc/notoc-direct-1.c, I accidentally left in '+'
characters in column 1 of the first three lines, which caused the test
case failure.
Bootstrapped and tested on powerpc64le-unknown-linux-gnu with that
fixed. Is this okay for t
Jiufu Guo writes:
> Hi,
>
> This patch implements a new opportunity of jump threading for PR77820.
> In this optimization, conditional jumps are merged with unconditional
> jump. And then moving CMP result to GPR is eliminated.
>
> This version is based on the proposal of Richard, Jeff and Andrew
On Fri, 24 May 2019, Segher Boessenkool wrote:
> IMO the best we can do is use what we already have: what CVS or SVN used
> as the committer identity. *That* info is *correct* at least.
CVS and SVN have a local identity. git has a global identity. I consider
it simply *incorrect* to put a loc
We don't need to pass to mcount the exact start of the called routine. This
saves
one instruction when long calls are being used.
Tested on hppa-unknown-linux-gnu, hppa2.0w-hp-hpux11.11 and hppa64-hp-hpux11.11.
Committed to trunk, gcc-9 and gcc-8 branches.
Dave
--
John David Anglin dave.ang..
On 23/05/19 07:39 +0200, François Dumont wrote:
Hi
So here what I come up with.
_GLIBCXX_DEBUG_BACKTRACE controls the feature. If the user define
Thanks for making this opt-in.
it and there is a detectable issue with libbacktrace then I generate a
compilation error. I want to avoid
This adds a new warning, -Wglobal-constructors, that warns whenever a
decl requires a global constructor or destructor. This new warning fires
whenever a thread_local or global variable is declared whose type has a
non-trivial constructor or destructor. When faced with both a constructor
and a dest
Okay.
thanks, I will add testing cases.
Qing
> On May 28, 2019, at 4:26 PM, David Malcolm wrote:
>
> On Tue, 2019-05-28 at 15:08 -0500, Qing Zhao wrote:
>> Hi, David,
>>
>> for this new option, do I need to add a new testing case for it?
>
> Yes please. Ideally we should add at least one tes
On Tue, 2019-05-28 at 15:08 -0500, Qing Zhao wrote:
> Hi, David,
>
> for this new option, do I need to add a new testing case for it?
Yes please. Ideally we should add at least one test case for any new
option, especially if it's easy to test for.
> if so, where should I put this new testing ca
Hi!
On Thu, 29 Jan 2015 09:28:38 +0100, I wrote:
> On Sat, 10 Jan 2015 20:21:46 +0100, I wrote:
> > On Wed, 12 Nov 2014 15:43:06 -0500, David Malcolm
> > wrote:
> > > On Wed, 2014-11-12 at 21:30 +0100, Jakub Jelinek wrote:
> > > > On Wed, Nov 12, 2014 at 03:22:21PM -0500, David Malcolm wrote:
>
Hi,
On 28/05/19 16:47, Jason Merrill wrote:
On 5/10/19 10:29 AM, Paolo Carlini wrote:
Hi,
a while ago Martin noticed that an unintended consequence of an old
tweak of mine - which avoided redundant error messages emitted from
cp_parser_init_declarator - is that, in some cases, we started
ac
Hi Martin,
On Tue, 28 May 2019 at 13:30, Martin Liška wrote:
>
> On 5/27/19 2:50 PM, Jakub Jelinek wrote:
> > On Mon, May 27, 2019 at 02:18:37PM +0200, Martin Liška wrote:
> >> +/* Compare loop information for basic blocks BB1 and BB2. */
> >> +
> >> +bool
> >> +func_checker::compare_loops (bas
On 5/28/19, Martin Sebor wrote:
> On 5/28/19 4:24 AM, Martin Liška wrote:
>> On 5/28/19 11:31 AM, David CARLIER wrote:
>>> Hi,
>>>
>>> Here a tiny patch to fix few build warnings.
>>>
>>> Kind regards.
>>>
>>
>> Hi.
>>
>> Well, I see a lot of these struct/class discrepancies when building GCC
>> w
Hi, David,
for this new option, do I need to add a new testing case for it?
if so, where should I put this new testing case?
thanks.
Qing
> On May 24, 2019, at 1:47 PM, David Malcolm wrote:
>
> On Fri, 2019-05-24 at 11:59 -0500, Qing Zhao wrote:
>> Hi,
>>
>> in order to fix PR90581: (provide
On 28/05/19 17:10 +0100, Jonathan Wakely wrote:
PR libstdc++/90634
* src/filesystem/path.cc (path::_M_split_cmpts()): Fix check for "/".
* testsuite/27_io/filesystem/path/construct/90634.cc: New test.
* testsuite/experimental/filesystem/path/construct/90634.cc: New
On 22/05/19 23:14 +0100, Jonathan Wakely wrote:
PR libstdc++/90557
* src/c++17/fs_path.cc (path::_List::operator=(const _List&)): Fix
reversed arguments to uninitialized_copy_n.
* testsuite/27_io/filesystem/path/assign/copy.cc: Check that source
is unchange
On 5/24/19 9:49 AM, Alex Henrie wrote:
On Fri, May 24, 2019 at 2:01 AM Richard Biener wrote:
I'm not sure we really need a new warning for this.
On Fri, May 24, 2019 at 9:23 AM Martin Sebor wrote:
I don't think GCC makes a formal distinction between function
attributes that affect only fu
This fixes and simplifies the setjmp and non-local goto implementation.
Currently the virtual frame pointer is saved when using __builtin_setjmp or
a non-local goto. Depending on whether a frame pointer is used, this may
either save SP or FP with an immediate offset. However the goto or longjmp
a
On 5/28/19 9:48 AM, Jakub Jelinek wrote:
> On Tue, May 28, 2019 at 08:30:59AM -0700, H.J. Lu wrote:
>>> We shouldn't generate ENDBR in that case, nothing can goto to bar (otherwise
>>> it would remain a normal label, not a deleted label).
>>>
>>
>> But return value of func () may be used with indir
Improve the fix for PR64242. Various optimizations can change a memory
reference
into a frame access. Given there are multiple virtual frame pointers which may
be replaced by multiple hard frame pointers, there are no checks for writes to
the
various frame pointers. So updates to a frame point
In aarch64_classify_symbol symbols are allowed full-range offsets on
relocations.
This means the offset can use all of the +/-4GB offset, leaving no offset
available
for the symbol itself. This results in relocation overflow and link-time errors
for simple expressions like &global_char + 0x
PR81800 is about the lrint inline giving spurious FE_INEXACT exceptions.
The previous change for PR81800 didn't fix this: when lrint is disabled
in the backend, the midend will simply use llrint. This actually makes
things worse since llrint now also ignores FE_INVALID exceptions!
The fix is to di
In tracking a surprise on the modules branch, I came across this code in
duplicate decls. Why would the newly minted decl already have
specializations? That smells wrong.
This chainon call was added by Mark Mitchell back in 1998, (rev 21876)
to deal with template friends of templates. Since
On 5/28/19 4:24 AM, Martin Liška wrote:
On 5/28/19 11:31 AM, David CARLIER wrote:
Hi,
Here a tiny patch to fix few build warnings.
Kind regards.
Hi.
Well, I see a lot of these struct/class discrepancies when building GCC with
LLVM.
Question is whether it worth changing?
I think it's nic
On 26/05/19 19:46 +0200, Gerald Pfeifer wrote:
The links adjustment I would just have committed right away, but
I'd also like to suggest swe simplify the section: the following
paragraph doesn't really add much, but duplicates the external
link.
Thoughts?
It's the same link, but not the same r
PR libstdc++/90634
* src/filesystem/path.cc (path::_M_split_cmpts()): Fix check for "/".
* testsuite/27_io/filesystem/path/construct/90634.cc: New test.
* testsuite/experimental/filesystem/path/construct/90634.cc: New test.
PR libstdc++/90634
* incl
On Tue, May 28, 2019 at 08:30:59AM -0700, H.J. Lu wrote:
> > We shouldn't generate ENDBR in that case, nothing can goto to bar (otherwise
> > it would remain a normal label, not a deleted label).
> >
>
> But return value of func () may be used with indirect jump.
No, it may be used say to print t
On 5/10/19 3:21 PM, Marek Polacek wrote:
Coming back to this. I didn't think this was suitable for GCC 9.
On Mon, Jan 07, 2019 at 10:44:37AM -0500, Jason Merrill wrote:
On 12/19/18 3:27 PM, Marek Polacek wrote:
Prompted by Jon's observation in 52869, I noticed that we don't treat
a noexcept-s
TL;DR: instead of capping TYPE_PRECISION of bitsizetype at
MAX_FIXED_MODE_SIZE, search for the largest fitting size from
scalar_int_mode modes supported by the target using
targetm.scalar_mode_supported_p.
-
In initialize_sizetypes, MAX_FIXED_MODE_SIZE is used as an upper
limit to the *pre
On 5/21/19 3:53 AM, Richard Biener wrote:
On Tue, May 21, 2019 at 4:13 AM Martin Sebor wrote:
On 5/20/19 3:16 AM, Richard Biener wrote:
On Mon, May 20, 2019 at 10:16 AM Marc Glisse wrote:
On Mon, 20 May 2019, Richard Biener wrote:
On Sun, May 19, 2019 at 6:16 PM Marc Glisse wrote:
Hel
On Tue, May 28, 2019 at 8:16 AM Jakub Jelinek wrote:
>
> On Tue, May 28, 2019 at 08:10:19AM -0700, H.J. Lu wrote:
> > On Tue, May 28, 2019 at 1:57 AM Jakub Jelinek wrote:
> > >
> > > On Sat, Feb 16, 2019 at 07:02:11AM -0800, H.J. Lu wrote:
> > > > > For NOTE_INSN_DELETED_LABEL, we should check if
On Tue, May 28, 2019 at 08:10:19AM -0700, H.J. Lu wrote:
> On Tue, May 28, 2019 at 1:57 AM Jakub Jelinek wrote:
> >
> > On Sat, Feb 16, 2019 at 07:02:11AM -0800, H.J. Lu wrote:
> > > > For NOTE_INSN_DELETED_LABEL, we should check if forced_labels to see
> > > > if its address is taken. Also ix86_
On Tue, May 28, 2019 at 1:57 AM Jakub Jelinek wrote:
>
> On Sat, Feb 16, 2019 at 07:02:11AM -0800, H.J. Lu wrote:
> > > For NOTE_INSN_DELETED_LABEL, we should check if forced_labels to see
> > > if its address is taken. Also ix86_init_large_pic_reg shouldn't set
> > > LABEL_PRESERVE_P (in_struct)
v2:
- use aarch64_simd_decl_p to check for aarch64_vector_pcs.
- emit the .variant_pcs directive even for local functions.
- don't require .variant_pcs asm support in compile only tests.
- add weakref tests.
A dynamic linker with lazy binding support may need to handle vector PCS
function symbols
On 5/28/19 10:19 AM, Jakub Jelinek wrote:
On Tue, May 28, 2019 at 10:07:12AM -0400, Jason Merrill wrote:
"or captures a structured binding (explicitly or implicitly), the program is
ill-formed."
Is P0588R1 a DR that would be applied to older standards?
P0588 was certainly intended to apply to
On 5/10/19 10:29 AM, Paolo Carlini wrote:
Hi,
a while ago Martin noticed that an unintended consequence of an old
tweak of mine - which avoided redundant error messages emitted from
cp_parser_init_declarator - is that, in some cases, we started accepting
ill-formed typeofs. Luckily, decltype
Hi,
This patch implements the [u]avgM3_floor and [u]avgM3_ceil optabs for SVE2.
Alejandro
gcc/ChangeLog:
2019-05-28 Alejandro Martinez
* config/aarch64/aarch64-sve2.md: New file.
(avg3_floor): New pattern.
(avg3_ceil): Likewise.
(*h): Likewise.
* conf
On Tue, May 28, 2019 at 10:07:12AM -0400, Jason Merrill wrote:
> > "or captures a structured binding (explicitly or implicitly), the program is
> > ill-formed."
> > Is P0588R1 a DR that would be applied to older standards?
>
> P0588 was certainly intended to apply to C++17, but I'd treat this as
>
On 5/20/19 5:44 PM, Jakub Jelinek wrote:
Hi!
The following patch is an attempt at implementing these two papers.
I must be missing something important, because in P1091R3 the rationale
talks about the intent to support structured bindings with static,
thread_local, constexpr, inline and extern,
Hi,
This patch implements a new opportunity of jump threading for PR77820.
In this optimization, conditional jumps are merged with unconditional
jump. And then moving CMP result to GPR is eliminated.
This version is based on the proposal of Richard, Jeff and Andrew, and
refined to incorporate com
On 5/28/19 9:11 AM, Jakub Jelinek wrote:
On Tue, May 28, 2019 at 08:59:57AM -0400, Jason Merrill wrote:
On 5/27/19 5:20 PM, Jakub Jelinek wrote:
As the testcase shows, we are silently accepting writes into const
variables, because the type generic builtins don't have a prototype.
Fixed thusly,
This fixes light fallout from recent changes in our loop optimizer. The
tests in question want to look at the codegen for the loop and thus
turning them into mem* calls isn't helpful.
Easiest thing to do is just disable loop distribution. COmmitted to the
trunk.
Jeff
* testsuite/gcc.tar
On Tue, May 28, 2019 at 08:59:57AM -0400, Jason Merrill wrote:
> On 5/27/19 5:20 PM, Jakub Jelinek wrote:
> > As the testcase shows, we are silently accepting writes into const
> > variables, because the type generic builtins don't have a prototype.
> >
> > Fixed thusly, bootstrapped/regtested on
On 5/27/19 5:20 PM, Jakub Jelinek wrote:
Hi!
As the testcase shows, we are silently accepting writes into const
variables, because the type generic builtins don't have a prototype.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?
2019-05-27 Jakub Jelinek
On 5/22/19 5:50 PM, Marek Polacek wrote:
On Wed, May 22, 2019 at 12:17:04AM -0400, Jason Merrill wrote:
On 5/20/19 6:08 PM, Marek Polacek wrote:
We ICE here because we are accessing call_args even though it's empty:
(gdb) p (*call_args).is_empty()
$5 = true
It's empty because the pack process
Kugan Vivekanandarajah writes:
> +/* Return the preferred mem scale factor for accessing MEM_MODE
> + of BASE which is optimized for SPEED. */
Maybe:
/* Return the preferred index scale factor for accessing memory of mode
MEM_MODE in the address space of pointer BASE. Assume that we're
Hi,
On Tue, May 28 2019, Jakub Jelinek wrote:
> On Tue, May 28, 2019 at 01:29:54PM +0200, Martin Liška wrote:
>> Yes, makes sense.
>>
>> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ok, thanks.
>
>> > BTW, unrelated to this patch, what does ICF do if e.g. SSA_NAME_PT
Yes I sort of agree it is pretty harmless even though I cannot tell
for Microsoft toolchain issue here.
On Tue, 28 May 2019 at 10:27, Jakub Jelinek wrote:
>
> On Tue, May 28, 2019 at 12:24:12PM +0200, Martin Liška wrote:
> > Well, I see a lot of these struct/class discrepancies when building GCC
On Fri, May 03, 2019 at 12:59:02PM +0200, Martin Liška wrote:
> 2019-05-03 Martin Liska
>
> PR other/90315
> * opts-global.c (decode_options): Print help for all
> help_option_arguments.
> * opts.c (print_help): Add new argument.
> (common_handle_option): Remember
Hi.
There are 3 backports that touch g++.dg/ipa/pr89009.C test-case.
Thanks,
Martin
>From 32fea51fa1294abb7c2aface7fc302406ff182cd Mon Sep 17 00:00:00 2001
From: sandra
Date: Sun, 21 Apr 2019 02:01:36 +
Subject: [PATCH 3/3] Backport r270476
gcc/testsuite/ChangeLog:
2019-04-20 Sandra Loose
On 5/28/19 1:41 PM, Jakub Jelinek wrote:
> On Tue, May 28, 2019 at 01:29:54PM +0200, Martin Liška wrote:
>> Yes, makes sense.
>>
>> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ok, thanks.
>
>>> BTW, unrelated to this patch, what does ICF do if e.g. SSA_NAME_PTR_INFO
On Tue, May 28, 2019 at 01:29:54PM +0200, Martin Liška wrote:
> Yes, makes sense.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ok, thanks.
> > BTW, unrelated to this patch, what does ICF do if e.g. SSA_NAME_PTR_INFO
> > or SSA_NAME_RANGE_INFO is different between ot
This removes the unnecessary restriction to 32-bit (all three ways).
It also scans for mtvsr*, not just mtvsrd. Finally, it uses the "wa"
constraints instead of "wi" in the inline asm statements.
Tested as usual; committing to trunk.
Segher
2019-05-28 Segher Boessenkool
gcc/testsuite/
On 5/27/19 2:50 PM, Jakub Jelinek wrote:
> On Mon, May 27, 2019 at 02:18:37PM +0200, Martin Liška wrote:
>> +/* Compare loop information for basic blocks BB1 and BB2. */
>> +
>> +bool
>> +func_checker::compare_loops (basic_block bb1, basic_block bb2)
>> +{
>> + if ((bb1->loop_father == NULL) != (
Rainer Orth writes:
> When reviewing how this patch
>
> [PATCH] gcc: move assemble_start_function / assemble_end_function to
> output_mi_thunk
> https://gcc.gnu.org/ml/gcc-patches/2019-05/msg00722.html
>
> might affect Solaris, I noticed an obsolete comment
>
> Note that use_thun
Kugan Vivekanandarajah writes:
> [...]
> diff --git a/gcc/tree-vect-loop-manip.c b/gcc/tree-vect-loop-manip.c
> index b3fae5b..c15b8a2 100644
> --- a/gcc/tree-vect-loop-manip.c
> +++ b/gcc/tree-vect-loop-manip.c
> @@ -415,10 +415,16 @@ vect_set_loop_masks_directly (struct loop *loop,
> loop_vec_i
Hi Everyone,
What can I say, I was too optimistic about how easy it would be to convert
GCC's svn repo to git one branch at a time. After 2 more weeks and several
re-writes of the scripts I now know more about GCC's svn history than I would
ever wanted.
The prize for most complicated branch h
-- Forwarded message -
From: David CARLIER
Date: Tue, 28 May 2019 at 10:16
Subject: Re: [PATCH] Fix few build warnings with LLVM toolchain
To: Segher Boessenkool
All right, here an updated version, hope it looks better.
Thanks.
On Tue, 28 May 2019 at 10:09, Segher Boessenkool
On Tue, May 28, 2019 at 12:24:12PM +0200, Martin Liška wrote:
> Well, I see a lot of these struct/class discrepancies when building GCC with
> LLVM.
> Question is whether it worth changing?
No, the warning is just wrong. C++ clearly states what the struct and class
keyword mean and it is just fi
On 5/28/19 11:31 AM, David CARLIER wrote:
> Hi,
>
> Here a tiny patch to fix few build warnings.
>
> Kind regards.
>
Hi.
Well, I see a lot of these struct/class discrepancies when building GCC with
LLVM.
Question is whether it worth changing?
Martin
On Tue, May 28, 2019 at 09:31:18AM +, David CARLIER wrote:
> Here a tiny patch to fix few build warnings.
Please mention what the warning _is_, and why it is correct / why it is
a good idea to make these changes.
Segher
Hi,
Here a tiny patch to fix few build warnings.
Kind regards.
Index: gcc/ChangeLog
===
--- gcc/ChangeLog (revision 271684)
+++ gcc/ChangeLog (working copy)
@@ -1,3 +1,7 @@
+2019-05-28 David Carlier
+
+* coretypes.h: Fix bu
On Mon, May 27, 2019 at 11:33:00PM +0200, Thomas Schwinge wrote:
> Why exactly are you objecting that the compiler produces useful
> intermediate dumps, understandable my machine and human?
While still not convinced we need this, if we add it, you are still
printing a lot of stuff that is useless
On Sat, Feb 16, 2019 at 07:02:11AM -0800, H.J. Lu wrote:
> > For NOTE_INSN_DELETED_LABEL, we should check if forced_labels to see
> > if its address is taken. Also ix86_init_large_pic_reg shouldn't set
> > LABEL_PRESERVE_P (in_struct) since NOTE_INSN_DELETED_LABEL is suffcient
> > to keep the labe
This adds support for the following function attributes in Ada: no_icf, noipa,
flatten, used, cold, hot, target and target_clones. They are supported by
means of the pragma Machine_Attribute, whose syntax is extended to accept
more than one optional parameter for the latter attribute.
Tested on x
The compiler allocates the non-packed size for a function returning a
parameter of an unconstrained packed array type.
Tested on x86_64-suse-linux, applied on the mainline and 9 branch.
2019-05-28 Eric Botcazou
* gcc-interface/trans.c (lvalue_required_for_attribute_p): Return 0
This is a regression present on all active branches. The compiler segfaults
on a function returning an array variable declared locally and used in a
grandchild function but not in its parent function (which is a child of the
first function).
Tested on x86_64-suse-linux, applied on all active b
The compiler segfaults on the extension of a tagged record type with variable
size subject to a partial representation clause, which is quite pathological.
Tested on x86_64-suse-linux, applied on the mainline and 9 branch.
2019-05-28 Eric Botcazou
* gcc-interface/decl.c (components_
This adds support for __builtin_prefetch in Ada.
Tested on x86_64-suse-linux, applied on the mainline.
2019-05-28 Eric Botcazou
* gcc-interface/decl.c (intrin_arglists_compatible_p): Do not return
false if the internal builtin uses a variable list.
2019-05-28 Eric Botcazou
71 matches
Mail list logo
