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.
*
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
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).
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
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
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
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
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
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
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 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
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
On Mon, Sep 16, 2019 at 08:56:58AM +0200, Richard Biener wrote:
> > As mentioned in the PR, the sqrt (x) < c optimization into x < c*c
> > sometimes breaks the boundary case, if c2=c*c is inexact then in some cases
> > we need to optimize it into x <= c*c rather than x < c*c. The original
> >
As diagnosed in the PR.
* config/aarch64/lse.S (LDNM): Ensure STXR output does not
overlap the inputs.
---
libgcc/config/aarch64/lse.S | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libgcc/config/aarch64/lse.S b/libgcc/config/aarch64/lse.S
index
Tested on aarch64-linux (glibc) and aarch64-elf (installed newlib).
The existing configure claims to be generated by 2.69, but there
are changes wrt the autoconf distributed with Ubuntu 18. Nothing
that seems untoward though.
r~
* config/aarch64/lse-init.c: Include auto-target.h.
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 decay_conversion saw that the bit-field reference was
> unchanged,
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 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
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
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
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
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
>
>
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.).
> 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
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
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.
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
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 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
29 matches
Mail list logo
