On 11/14/20 7:08 PM, David Edelsohn wrote:
> On Sat, Nov 14, 2020 at 8:58 PM Jeff Law wrote:
>>
>> On 11/14/20 6:35 PM, David Edelsohn wrote:
Jeffrey Law wrote:
I worry a bit about the less common native targets -- aix, hpux and the
like. But testing them is too painful to co
Hi Thomas,
thanks for the comments.
> It feels a bit strange to have a check for an allocatable
> behind -fcheck=pointer, but I'm not sure that introducing
> a special check option would really be worth it.
Yes, I thought about that. There's already a discrepancy between
the GFC_RTCHECK_* in li
On Sun, Nov 15, 2020 at 11:57:55PM -1200, Jakub Jelinek via Gcc-patches wrote:
> Tested on x86_64-linux, i686-linux and powerpc64-linux, ok for trunk?
Here is an incremental patch that resolves the remaining FIXMEs, in
particular implements VLAs (except for variable length structures)
and for larg
Hi!
During the __builtin_clear_padding implementation, I've noticed we don't
diagnose _ATomic whatever * as last argument to __builtin_*_overflow.
As the storing by that builtin isn't atomic in any way, I think we should
reject it.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
2020-11-16
On Mon, Nov 16, 2020 at 10:17:19PM +0100, Jakub Jelinek via Gcc-patches wrote:
> Hi!
>
> During the __builtin_clear_padding implementation, I've noticed we don't
> diagnose _ATomic whatever * as last argument to __builtin_*_overflow.
> As the storing by that builtin isn't atomic in any way, I thin
Hi!
The test has been added 3 years before noipa attribute has been introduced,
but already at that point I wanted to avoid IPA opts getting into way,
most of the foo function is optimized away and the debug info just points
to the caller\s var. With the recent modref/aliasing changes the caller'
Hi
The changes in r11-4799 introduced a dummy enum rid type with
a different initial member name to the actual version (an ODR
violation). Fixed by including the header declaring the
actual type.
tested --with-build-config=bootstrap-lto on Linux and
--with-build-config=bootstrap-lto-noplugin o
Martin Liška wrote:
On 11/16/20 10:00 AM, Iain Sandoe wrote:
../../gcc/c-family/stub-objc.c:30: note: an enum with different value
name is defined in another translation unit
30 | enum rid { DUMMY };
I’m not disagreeing, of course (and will sort it out)..
.. but I don’t see this warning
On 11/16/20 2:24 PM, Marek Polacek wrote:
On Mon, Nov 16, 2020 at 02:02:00PM -0500, Jason Merrill via Gcc-patches wrote:
On 11/16/20 12:42 PM, Martin Sebor wrote:
On 11/15/20 3:44 PM, Marek Polacek via Gcc-patches wrote:
This patch implements the long-desired -Wuninitialized warning for
member
On 11/15/20 10:34 PM, Marek Polacek wrote:
[ This year's end-of-stage1 I'm working virtually from American Samoa. ]
This patch finishes the second half of -Wrange-loop-construct I promised
to implement: it warns when a loop variable in a range-based for-loop is
initialized with a value of a diff
On 11/13/20 10:43 AM, Patrick Palka wrote:
On Thu, 12 Nov 2020, Jason Merrill wrote:
On 11/12/20 1:27 PM, Patrick Palka wrote:
The atom_cache in normalize_atom relies on the assumption that two
equivalent (templated) trees (in the sense of cp_tree_equal) must use
the same template parameters (
On Mon, Nov 16, 2020 at 10:57 AM Philipp Tomsich
wrote:
> In case a negative shift operand makes it through into the backend,
> it will be treated as unsigned and truncated (using a mask) to fit
> into the range 0..31 (for SImode) and 0..63 (for DImode).
>
This is a de-optimization. This doesn'
On Mon, Nov 16, 2020 at 10:57 AM Philipp Tomsich
wrote:
> This adds simplify_using_ranges::simplify_lshift_using_ranges to
> detect and rewrite such cases. If the intersection of meaningful
> shift amounts for the underlying type and the value-range computed
> for the shift-amount (whether an in
This patch looks good to me.
It would be great to find a way to do a similar refactoring of
condition_variable.
> On Nov 12, 2020, at 9:07 AM, Jonathan Wakely via Libstdc++
> wrote:
>
> On 11/11/20 17:31 +, Jonathan Wakely wrote:
>> On 11/11/20 16:13 +, Jonathan Wakely wrote:
>>> This
Jim,
On Mon, 16 Nov 2020 at 23:28, Jim Wilson wrote:
>
> On Mon, Nov 16, 2020 at 10:57 AM Philipp Tomsich
wrote:
>>
>> In case a negative shift operand makes it through into the backend,
>> it will be treated as unsigned and truncated (using a mask) to fit
>> into the range 0..31 (for SImode) an
On Mon, 16 Nov 2020, Jason Merrill wrote:
> On 11/13/20 10:43 AM, Patrick Palka wrote:
> > On Thu, 12 Nov 2020, Jason Merrill wrote:
> >
> > > On 11/12/20 1:27 PM, Patrick Palka wrote:
> > > > The atom_cache in normalize_atom relies on the assumption that two
> > > > equivalent (templated) trees
On 3/11/20 7:34 AM, Nidal Faour via Gcc-patches wrote:
> This patch is a code density oriented and attempt to remove redundant
> sign/zero extension from assignment statement.
> The approach taken is to use VRP data while expanding the assignment to RTL
> to determine whether a sign/zero extens
On Sun, 15 Nov 2020, Uecker, Martin wrote:
> > I think it might be safest to avoid doing any conversion in the case where
> > the value is still of array type at this point (C90 non-lvalue arrays).
>
> I added a test for arrays, but I am not sure what effect it has.
> What would be C90 non-lvalu
On Mon, 16 Nov 2020 at 23:38, Jim Wilson wrote:
> On Mon, Nov 16, 2020 at 10:57 AM Philipp Tomsich
> wrote:
>
>> This adds simplify_using_ranges::simplify_lshift_using_ranges to
>> detect and rewrite such cases. If the intersection of meaningful
>> shift amounts for the underlying type and the
On Tue, 27 Oct 2020, Tamar Christina via Gcc-patches wrote:
> Hi All,
>
> This patch fixes an issue where on systems that are
> HAVE_TARGET_EXECUTABLE_SUFFIX the driver calls convert_filename in order to
> add the suffix to the filename. However while it excludes `-` it doesn't
> exclude the nul
On Mon, Nov 16, 2020 at 3:41 PM Jeff Law wrote:
>
> On 11/14/20 7:08 PM, David Edelsohn wrote:
> > On Sat, Nov 14, 2020 at 8:58 PM Jeff Law wrote:
> >>
> >> On 11/14/20 6:35 PM, David Edelsohn wrote:
> Jeffrey Law wrote:
> I worry a bit about the less common native targets -- aix, h
The -Wmaybe-uninitialized enhancement to warn when the address
of an uninitialized object is passed to a function taking a const
pointer (or, in C++, a const reference) tries to avoid triggering
when the address is that of an empty object. It does that by
checking EMPTY_TYPE_P() and default_is_em
I've gone ahead and pushed this website change, having checked it
validates.
Dave
---
htdocs/gcc-11/changes.html | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/htdocs/gcc-11/changes.html b/htdocs/gcc-11/changes.html
index 798257aa..21d59f51 100644
--- a/htdocs
I've gone ahead and pushed this website change, adding a new section
to cover analyzer changes, having checked it validates.
Dave
---
htdocs/gcc-11/changes.html | 32
1 file changed, 32 insertions(+)
diff --git a/htdocs/gcc-11/changes.html b/htdocs/gcc-11/change
On 11/16/20 4:22 PM, Martin Sebor via Gcc-patches wrote:
> The -Wmaybe-uninitialized enhancement to warn when the address
> of an uninitialized object is passed to a function taking a const
> pointer (or, in C++, a const reference) tries to avoid triggering
> when the address is that of an empty
On 11/16/20 11:57 AM, Philipp Tomsich wrote:
> From: Philipp Tomsich
>
> While most shifts wider than the bitwidth of a type will be caught by
> other passes, it is possible that these show up for VRP.
> Consider the following example:
> int func (int a, int b, int c)
> {
> return (a <<
On Mon, Nov 16, 2020 at 05:02:14PM -0500, Jason Merrill via Gcc-patches wrote:
> On 11/15/20 10:34 PM, Marek Polacek wrote:
> > [ This year's end-of-stage1 I'm working virtually from American Samoa. ]
> >
> > This patch finishes the second half of -Wrange-loop-construct I promised
> > to implement
On 11/16/20 2:04 AM, Richard Biener via Gcc-patches wrote:
> On Sun, Nov 15, 2020 at 1:46 AM Martin Sebor via Gcc-patches
> wrote:
>> GCC considers PTRDIFF_MAX - 1 to be the size of the largest object
>> so that the difference between a pointer to the byte just past its
>> end and the first one
On 8/17/20 4:42 AM, Roger Sayle wrote:
> This patch catches a missed optimization opportunity where GCC currently
> generates worse code than LLVM. The issue, as nicely analyzed in bugzilla,
> boils down to the following three insns in combine:
>
> (insn 6 5 7 2 (parallel [
> (set (r
On 9/2/20 3:34 AM, Hongtao Liu via Gcc-patches wrote:
> Hi:
> Add define_peephole2 to eliminate potential redundant conversion
> from mask to vector.
> Bootstrap is ok, regression test is ok for i386/x86-64 backend.
> Ok for trunk?
>
> gcc/ChangeLog:
> PR target/96891
> * co
On 9/3/20 3:39 AM, Hongtao Liu via Gcc-patches wrote:
> Hi:
> Add define_peephole2 to perform optimization like bellow:
>
> +/* Optimize for TARGET_AVX512F
> + vpsubusw op1, op2, dst1;
> + vxorps xmm, xmm, dst2; > vpcmpleuw op1, op2, dst3
> + vpcmpeqw dst1, dst2, dst3 */
>
> and
>
> +
Clang's "unsigned integer overflow" sanitizer can't tell the difference
between expected unsigned wraparound and a bug, and its developers tell
users to report bugs against libstdc++.
This disables the sanitizer where we are intentionally relying on
wraparound working as defined by the standard.
On 9/6/20 9:23 AM, Armin Brauns via Gcc-patches wrote:
> gcc/ChangeLog:
> * gcc.c: document %T spec file directive
> * doc/invoke.texi:
> remove %p, %P spec file directives
> add %M, %R, %V, %nSTR, %>S, % file directives
> add sanitize, version-compare, include, gt a
On 9/29/20 7:56 AM, Mark Wielaard wrote:
> On Thu, 2020-09-10 at 13:16 +0200, Jakub Jelinek wrote:
>> On Wed, Sep 09, 2020 at 09:57:54PM +0200, Mark Wielaard wrote:
>>> --- a/gcc/doc/invoke.texi
>>> +++ b/gcc/doc/invoke.texi
>>> @@ -9057,13 +9057,14 @@ possible.
>>> @opindex gdwarf
>>> Produce
On 10/26/20 6:44 PM, Joseph Myers wrote:
> C2x adds macros for NaNs and infinities to , some of them
> previously in (and some still in as well in C2x as
> an obsolescent feature). Add these macros to GCC's
> implementation.
>
> This omits the macros for DFP signaling NaNs, leaving those to b
From: Aaron Sawdey
Richard,
Thanks for the review. I think I have resolved everything, as follows:
* I was able to remove the const_tiny_rtx initialization for
MODE_OPAQUE. If that becomes a problem it's a pretty simple matter to
use an UNSPEC to assign a constant to an opaque mode if necessa
On 11/2/20 3:40 AM, FX via Gcc-patches wrote:
> Here is an updated patch, that quotes all three makeinfo special characters:
> @ { }
> Tested on a build with source directory /tmp/foo@bar{gee}qux
>
> OK to commit?
OK. You have commit privs, right?
jeff
On 11/13/20 2:44 PM, Jeff Law via Gcc-patches wrote:
On 10/5/20 5:12 PM, David Malcolm via Gcc-patches wrote:
This work-in-progress patch generalizes the malloc/free problem-checking
in -fanalyzer so that it can work on arbitrary acquire/release API pairs.
It adds a new __attribute__((dealloca
On 11/3/20 4:56 PM, Martin Sebor via Gcc-patches wrote:
> Attached is a simple middle end implementation of detection of
> mismatched pairs of calls to C++ new and delete, along with
> a substantially enhanced implementation of -Wfree-nonheap-object.
> The latter option has been in place since 20
On 11/9/20 11:57 AM, H.J. Lu via Gcc-patches wrote:
> GCC 11 supports -march=x86-64-v[234] to enable x86 micro-architecture ISA
> levels:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97250
>
> Binutils has been updated to support GNU_PROPERTY_X86_ISA_1_V[234] marker:
>
> https://gitlab.com/x8
On 11/16/20 2:53 AM, Martin Liška wrote:
> On 11/9/20 4:56 PM, Jeff Law wrote:
>>
>> On 11/9/20 7:24 AM, Martin Liška wrote:
>>> Hello.
>>>
>>> As mentioned in the PR, we used to prefer BT over JT in switch
>>> expansion.
>>> I restore the behavior to that.
>>>
>>> Patch can bootstrap on x86
On 11/3/20 2:14 PM, Nathan Sidwell wrote:
> As I mentioned in patch 03, include translation is a thing. This
> amends the file handling to determine that, and for resolving explicit
> imports of header-units
>
> The logic for locating a header unit is the same as locating a
> header-file. Excep
On 11/15/20 2:14 PM, Jozef Lawrynowicz wrote:
> The attached patch series improves MSP430 hardware multiply support, by
> improving code generation when setting up the 16-bit and 32-bit hardware
> multiply functions, and adding a 64-bit hardware multiply library
> function for devices that have
On 11/15/20 2:12 PM, Maciej W. Rozycki wrote:
> On Tue, 10 Nov 2020, Jeff Law via Gcc-patches wrote:
>
> This patch reduce reservation of model do not more than 10 cycles. The
> memory of genautomata down to 1GB.
How bad is the memory consumption before this change?
>>> almost
On 11/15/20 10:44 AM, Maciej W. Rozycki wrote:
> Disable USE_PT_GNU_EH_FRAME frame unwinder support for old OS versions,
> fixing compilation errors:
>
> .../libgcc/unwind-dw2-fde-dip.c:75:21: error: unknown type name 'Elf_Phdr'
>75 | # define ElfW(type) Elf_##type
> |
On Mon, Nov 16, 2020 at 4:58 PM Jeff Law wrote:
>
>
> On 11/9/20 11:57 AM, H.J. Lu via Gcc-patches wrote:
> > GCC 11 supports -march=x86-64-v[234] to enable x86 micro-architecture ISA
> > levels:
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97250
> >
> > Binutils has been updated to suppor
Thank you for the review Richard!
I re-worked the patch based on your suggestions (attached).
I made the change to reuse the first bit_xor in both patterns and I added :s to
the last xor in the first pattern.
For the second pattern I didn't add :s because I think the simplification is
beneficial
On Tue, 8 Sep 2020, Patrick McGehearty via Gcc-patches wrote:
> This project started with an investigation related to
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59714. Study of Beebe[1]
> provided an overview of past and recent practice for computing complex
> divide. The current glibc implem
The result of DECL_SIZE_UNIT doesn't always reflect the size
of data members of virtual classes. This can lead to objects
of such types appearing smaller than they are to warnings like
-Warray-bounds or -Wstringop-overflow, causing false positives.
To avoid these false positives, the attached re
[dcl.constexpr]/3 says that the function-body of a constexpr function
shall not contain an identifier label, but we aren't enforcing that.
This patch implements that. Of course, we can't reject artificial
labels.
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
gcc/cp/ChangeLog:
On Tue, Nov 17, 2020 at 8:05 AM Jeff Law wrote:
>
>
> On 9/2/20 3:34 AM, Hongtao Liu via Gcc-patches wrote:
> > Hi:
> > Add define_peephole2 to eliminate potential redundant conversion
> > from mask to vector.
> > Bootstrap is ok, regression test is ok for i386/x86-64 backend.
> > Ok for tru
On 11/16/20 12:02 PM, Jason Merrill wrote:
On 11/16/20 12:42 PM, Martin Sebor wrote:
On 11/15/20 3:44 PM, Marek Polacek via Gcc-patches wrote:
This patch implements the long-desired -Wuninitialized warning for
member initializer lists, so that the front end can detect bugs like
struct A {
On Sun, 15 Nov 2020, Maciej W. Rozycki wrote:
> Hi,
>
> In the course of my recent VAX backend modernisation effort
Hi. That reminds me that VAX is "still" a cc0 target.
Are you aware of anyone planning on that level of modernization?
More than a year ago, there was a major heads-up that all
On Fri, 13 Nov 2020, H.J. Lu via Gcc-patches wrote:
> Done. Here is the updated patch.
Hi. I see a test-case for this kind of construct:
int foo __attribute__((__used__, __section__ (".bar"))) = 42;
and IIUC that it's handled as I'd hope (setting "R" on the named
section, not another derived
Ping...
I'd like to ping for this patch:
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/557886.html
Thanks
Bernd.
On 11/3/20 4:08 PM, Bernd Edlinger wrote:
> Hi,
>
> this fixes a problem with a missing symbol __sync_synchronize
> which happens when newlib is used together with libstdc+
Hi，
I just tweaked the patch according to your advice and committed it.
Thanks so much for your help and advice.
Haochen Gui
On 13/11/2020 下午 5:27, Richard Sandiford wrote:
Hi,
Sorry for the slow reply. Just one minor nit:
HAO CHEN GUI writes:
diff --git a/gcc/varasm.c b/gcc/varasm.c
in
On 2020-11-16 17:35, Richard Biener wrote:
On Mon, Nov 16, 2020 at 10:26 AM Jiufu Guo
wrote:
Jiufu Guo writes:
> Richard Biener writes:
>
>> On Wed, 11 Nov 2020, Jiufu Guo wrote:
>>
>>>
>>> Thanks a lot for the suggestion from previous mails.
>>> The patch was updated accordingly.
>>>
>>> T
On 11/16/20 10:13 PM, Martin Sebor wrote:
On 11/16/20 12:02 PM, Jason Merrill wrote:
On 11/16/20 12:42 PM, Martin Sebor wrote:
On 11/15/20 3:44 PM, Marek Polacek via Gcc-patches wrote:
This patch implements the long-desired -Wuninitialized warning for
member initializer lists, so that the fron
On 11/16/20 9:41 PM, Martin Sebor wrote:
The result of DECL_SIZE_UNIT doesn't always reflect the size
of data members of virtual classes. This can lead to objects
of such types appearing smaller than they are to warnings like
-Warray-bounds or -Wstringop-overflow, causing false positives.
To av
On Mon, 16 Nov 2020, Jakub Jelinek wrote:
> Hi!
>
> The test has been added 3 years before noipa attribute has been introduced,
> but already at that point I wanted to avoid IPA opts getting into way,
> most of the foo function is optimized away and the debug info just points
> to the caller\s va
On Mon, 16 Nov 2020, Tamar Christina wrote:
> Hi Richi, thanks for the review!
>
> Just a quick comment on one of the questions asked:
>
> > -Original Message-
> > From: rguent...@c653.arch.suse.de On
> > Behalf Of Richard Biener
> > Sent: Monday, November 16, 2020 3:12 PM
> > To: Tamar
On Tue, Nov 17, 2020 at 3:19 AM Eugene Rozenfeld
wrote:
>
> Thank you for the review Richard!
>
> I re-worked the patch based on your suggestions (attached).
> I made the change to reuse the first bit_xor in both patterns and I added :s
> to the last xor in the first pattern.
> For the second pat
101 - 162 of 162 matches
Mail list logo
