On 9/19/19 3:40 PM, Marek Polacek wrote:
This is an ICE that started with the recent r275745. The problem here is that
for a POSTINCREMENT_EXPR build_new_op_1 is called with null arg2, so arg2_type
is
also null after
5819 tree arg2_type = arg2 ? unlowered_expr_type (arg2) : NULL_TREE;
but t
On Fri, Sep 20, 2019 at 04:50:12PM -0600, Jeff Law wrote:
> On 9/12/19 7:33 AM, Jonas Pfeil wrote:
> > A type confusion leads to illegal (and nonsensical) assembly on certain host
> > architectures (e.g. ARM), where HOST_WIDE_INT (64 bit) and unsigned long (32
> > bit) have different alignments. So
On Sat, Sep 21, 2019 at 05:32:03PM -0400, Jason Merrill wrote:
> On Sat, Sep 21, 2019 at 2:18 PM Segher Boessenkool
> wrote:
> >
> > On Thu, Sep 19, 2019 at 03:29:27PM -0400, Jason Merrill wrote:
> > > I suppose we also need to decide what form we want to use for the
> > > equivalent of gcc.gnu.or
The new get_range_strlen_dynamic function has a couple of bugs
where it assumes that the length range bounds it gets back from
get_range_strlen are non-null integer constants. The attached
"quick and dirty" fix removes those assumptions. Since it's
apparently causing package failures in Jeff's G
On Sat, Sep 21, 2019 at 03:04:26PM -0600, Jeff Law wrote:
> On 9/21/19 2:48 PM, Paul Koning wrote:
> >> On Sep 20, 2019, at 1:45 PM, Jeff Law wrote:
> >> On 9/20/19 11:22 AM, Richard Biener wrote:
> >> Now if someone did a variant #2 without the optimization bits (ie,
> >> adding appropriate _set
The recent improvement to -Warray-bounds to detect past-the-end
accesses by string functions to member subobjects had a bug that
triggered a false positive in a Binutils build. In r276022 I've
committed the attached trivial fix to correct the bug.
Martin
Index: gcc/ChangeLog
===
On Sat, Sep 21, 2019 at 2:23 AM Jakub Jelinek wrote:
>
> On Mon, Sep 16, 2019 at 12:33:28AM -0400, Jason Merrill wrote:
> > Here, if cp_perform_integral_promotions saw that the TREE_TYPE of a
> > bit-field reference was the same as the type it promotes to, it didn't do
> > anything. But then deca
On Sat, Sep 21, 2019 at 2:18 PM Segher Boessenkool
wrote:
>
> On Thu, Sep 19, 2019 at 03:29:27PM -0400, Jason Merrill wrote:
> > I suppose we also need to decide what form we want to use for the
> > equivalent of gcc.gnu.org/rN. I figure it needs to be some prefix
> > followed by a "commit-is
On 9/21/19 2:48 PM, Paul Koning wrote:
>
>
>> On Sep 20, 2019, at 1:45 PM, Jeff Law wrote:
>>
>> On 9/20/19 11:22 AM, Richard Biener wrote:
>>> ... It seems to be that for the goal to keep a target alive a
>>> variant #2 conversion (according to the wiki) should be closely
>>> mirror CC0 behavi
> On Sep 20, 2019, at 1:45 PM, Jeff Law wrote:
>
> On 9/20/19 11:22 AM, Richard Biener wrote:
>> ...
>> It seems to be that for the goal to keep a target alive a variant #2
>> conversion (according to the wiki) should be closely mirror CC0
>> behavior and thus should be easier to achieve and w
On 9/21/19 2:18 PM, Segher Boessenkool wrote:
On Thu, Sep 19, 2019 at 03:29:27PM -0400, Jason Merrill wrote:
I suppose we also need to decide what form we want to use for the
equivalent of gcc.gnu.org/rN. I figure it needs to be some prefix
followed by a "commit-ish" (hash, tag, etc.). P
Some changes were missed here in the transition to LRA. The Darwin
archs are all using LRA now.
tested on i686-darwin9, x86_64-darwin16,
applied to mainline
thanks
Iain
gcc/ChangeLog:
2019-09-21 Iain Sandoe
* config/darwin.c (machopic_legitimize_pic_address): Check
for lra
On Thu, Sep 19, 2019 at 03:29:27PM -0400, Jason Merrill wrote:
> I suppose we also need to decide what form we want to use for the
> equivalent of gcc.gnu.org/rN. I figure it needs to be some prefix
> followed by a "commit-ish" (hash, tag, etc.). Perhaps "g:" as the
> prefix, so
>
> gcc.gnu.
On 21.09.2019 16:53, Jakub Jelinek wrote:
> On Fri, Sep 20, 2019 at 10:45:42PM +0200, Kamil Rytarowski wrote:
>> GCC version of https://reviews.llvm.org/D67719
>>
>> From 422827582d84e078df2a8e303d807c830a155ab5 Mon Sep 17 00:00:00 2001
>> From: Kamil Rytarowski
>> Date: Fri, 20 Sep 2019 22:02:09
On 21.09.2019 16:51, Jakub Jelinek wrote:
> On Sat, Sep 21, 2019 at 01:31:10PM +0200, Kamil Rytarowski wrote:
>> GCC version of https://reviews.llvm.org/D52386
>>
>> 2019-09-21 Kamil Rytarowski
>>
>> * cppbuiltin.c (define_builtin_macros_for_compilation_flags): Add new
>> builtin __SAN
On Fri, Sep 20, 2019 at 10:45:42PM +0200, Kamil Rytarowski wrote:
> GCC version of https://reviews.llvm.org/D67719
>
> From 422827582d84e078df2a8e303d807c830a155ab5 Mon Sep 17 00:00:00 2001
> From: Kamil Rytarowski
> Date: Fri, 20 Sep 2019 22:02:09 +0200
> Subject: [PATCH] 2019-09-20 Kamil Rytar
On Sat, Sep 21, 2019 at 01:31:10PM +0200, Kamil Rytarowski wrote:
> GCC version of https://reviews.llvm.org/D52386
>
> 2019-09-21 Kamil Rytarowski
>
> * cppbuiltin.c (define_builtin_macros_for_compilation_flags): Add new
> builtin __SANITIZE_UNDEFINED__ macros for fsanitize=undefin
Hi,
Thanks for doing this.
Martin Jambor writes:
> +/* Analyze function body scan results stored in param_accesses and
> + param_accesses, detect possible transformations and store information of
> + those in function summary. NODE, FUN and IFS are all various structures
> + describing th
Jumping across initializers is forbidden, and this DR clarifies that
that applies to initializers in init-statements too. We already detect
this case, so I'm adding this test and marking the DR as resolved.
Tested on x86_64-linux, applying to trunk.
2019-09-21 Marek Polacek
DR 2345 -
Hi David,
I think technically I can self-approve this, but I'm not a
day-to-day user of fortran; does this look sane?
Very much so, I also find this more readable.
I'd wait another day or so for comitting this, so that other people
with different aesthetic sense can also chime in if they want
On September 21, 2019 12:28:57 PM GMT+02:00, Christian Biesinger
wrote:
>On Sat, Sep 21, 2019 at 7:22 PM Richard Biener
> wrote:
>>
>> On September 21, 2019 11:12:38 AM GMT+02:00, Christian Biesinger via
>gcc-patches wrote:
>> >Hello,
>> >
>> >I would like to move hash-table.h, hash-map.h and re
GCC version of https://reviews.llvm.org/D52386
2019-09-21 Kamil Rytarowski
* cppbuiltin.c (define_builtin_macros_for_compilation_flags): Add new
builtin __SANITIZE_UNDEFINED__ macros for fsanitize=undefined switch.
* doc/cpp.texi: Document new macros.
* c-c++-c
On Sat, Sep 21, 2019 at 7:22 PM Richard Biener
wrote:
>
> On September 21, 2019 11:12:38 AM GMT+02:00, Christian Biesinger via
> gcc-patches wrote:
> >Hello,
> >
> >I would like to move hash-table.h, hash-map.h and related files
> >to libiberty, so that GDB can make use of it.
> >
> >I see that
On September 21, 2019 11:12:38 AM GMT+02:00, Christian Biesinger via
gcc-patches wrote:
>Hello,
>
>I would like to move hash-table.h, hash-map.h and related files
>to libiberty, so that GDB can make use of it.
>
>I see that gcc already has a C++ file in include/ (unique-ptr.h),
>which I understan
Hello,
I would like to move hash-table.h, hash-map.h and related files
to libiberty, so that GDB can make use of it.
I see that gcc already has a C++ file in include/ (unique-ptr.h),
which I understand is libiberty.
However, this patch is not complete yet (for a start, it doesn't
compile). Befor
25 matches
Mail list logo
