Hi Harald,
let's add a LGTM or OK to this – the patch is rather obvious and Steve
explained how the now-removed check ended up in gfortran.
Thanks for the patch!
Tobias
On 12/11/19 11:24 PM, Harald Anlauf wrote:
Hi Thomas,
Gesendet: Dienstag, 10. Dezember 2019 um 23:34 Uhr
Von: "Thomas Ko
On December 12, 2019 12:56:01 AM GMT+01:00, Jakub Jelinek
wrote:
>Hi!
>
>The AVX512{F,VL} vector comparisons that set %kN registers are
>represented
>in RTL as comparisons with vector mode operands and scalar integral
>result,
>where at runtime the scalar integer is filled with a bitmask.
>Unfort
On December 12, 2019 7:43:58 AM GMT+01:00, Stefan Franke
wrote:
>Am 2019-12-08 01:54, schrieb Oleg Endo:
>> On Tue, 2019-11-26 at 07:38 +0100, ste...@franke.ms wrote:
>>> > On 11/21/19 10:30 AM, ste...@franke.ms wrote:
>>> > > Hi there,
>>> > >
>>> > > here is mc68k's patch to switch the m68k arc
On Mon, Dec 09, 2019 at 02:16:51PM -0600, Peter Bergner wrote:
> I'm not sure that's necessary. DFP enablement isn't triggered by
> assembler support. Just the gcc/configure fragment (ignoring manually
> using --enable-decimal-float):
>
> case $target in
> powerpc*-*-linux* | i?86*-*-linux
Richard Biener writes:
> On December 12, 2019 12:56:01 AM GMT+01:00, Jakub Jelinek
> wrote:
>>Hi!
>>
>>The AVX512{F,VL} vector comparisons that set %kN registers are
>>represented
>>in RTL as comparisons with vector mode operands and scalar integral
>>result,
>>where at runtime the scalar intege
Stefan Franke writes:
> Am 2019-12-08 01:54, schrieb Oleg Endo:
>> On Tue, 2019-11-26 at 07:38 +0100, ste...@franke.ms wrote:
>>> > On 11/21/19 10:30 AM, ste...@franke.ms wrote:
>>> > > Hi there,
>>> > >
>>> > > here is mc68k's patch to switch the m68k architecture over to ccmode
>>> > > and
>>> >
Thank you for your review. Patch pushed to mainline and gcc9 branch.
//Claudiu
On Wed, Dec 11, 2019 at 8:59 PM Jeff Law wrote:
>
> On Mon, 2019-12-09 at 11:52 +0200, Claudiu Zissulescu wrote:
> > Although the FDCMP (the double precision floating point compare
> > instruction) is added to the com
Pushed. Thank you for your contribution,
Claudiu
On Wed, Dec 11, 2019 at 12:47 AM Vineet Gupta
wrote:
>
> On 12/10/19 1:12 AM, Claudiu Zissulescu wrote:
> > Hi,
> >
> > Thank you for your contribution, I'll push it asap. As far as I understand,
> > you need this patch both in gcc9 branch and mai
On Thu, Dec 12, 2019 at 09:22:47AM +, Richard Sandiford wrote:
> > So there's no whole vector equality RTX but we have to pun to integer
> > modes for that? The eq:SImode would suggest that. Guess we should have
> > used a BImode vector representation...
Probably something like
V2BImode/V4BI
Hi all,
This small patch adds support for the ARM v8.6 extensions +bf16 and
+i8mm to the testsuite. This will be tested through other upcoming
patches, which is why we are not providing any explicit tests here.
Ok for trunk?
Also I don't have commit rights, so if someone could commit on my
be
Add routine Get_Argument with End_Of_Arguments Boolean out parameter
into GNAT.Command_Line API to distinguish between the empty argument and
the end of arguments.
Tested on x86_64-pc-linux-gnu, committed on trunk
2019-12-12 Dmitriy Anisimkov
gcc/ada/
* libgnat/g-comlin.ads (Get_Argu
In addition to the C bindings automatically generated during the build
process (einfo.h, sinfo.h, snames.h), gigi also makes use of a manually
maintained C interface to the front-end (atree.h, elists.h, fe.h, namet.h,
nlists.h, repinfo.h, scos.h, stringt.h, types.h, uintp.h, urealp.h).
This change
This patch fixes an issue whereby the compiler crashes generating
accessibility checks for the attribute references 'Loop_Entry, 'Old, and
'Result when they are used as actuals.
Tested on x86_64-pc-linux-gnu, committed on trunk
2019-12-12 Justin Squirek
gcc/ada/
* exp_ch6.adb (Expand
This patch fixes an omission in the generation of constraint checks,
when assigning to a record component whose type is a constrained access
to a discriminated record.
Tested on x86_64-pc-linux-gnu, committed on trunk
2019-12-12 Ed Schonberg
gcc/ada/
* sem_ch3.adb (Constrain_Access):
AI12-0036 is a binding interpretation which adds the following legality
rule:
The actual type for a formal derived type shall be tagged if and only
if the formal derived type is a private extension.
Implement this new compile-time check. The check is implemented without
checking the value o
In the case described on this ticket, a predefined unit (the body of
Ada.Finalization) is recompiled with a configuration pragma in effect
(an Interrupt_State pragma) which has has the effect of introducing a
circular compilation dependency. Previously this resulted in an
internal error. With this
This patch fixes an issue whereby the compiler incorrectly resolves
non-visible controlled primitives such as the case where predefined
controlled operations get called on a type extension whose parent is
a private extension completed with a controlled extension.
Tested on x86_64-pc-linux-gnu, com
Correct the subtype used for a call to Last in Find_Index so that it no
longer crashes on empty vectors with checks enabled.
Tested on x86_64-pc-linux-gnu, committed on trunk
2019-12-12 Claire Dross
gcc/ada/
* libgnat/a-cofove.adb, libgnat/a-cfinve.adb (Find_Index): Use
Exten
The B940010 ACATS test includes some legality violations that GNAT was
failing to reject (at compile time). With this change these violations
are detected and appropriate error messages are produced. Most of the
required error messages that are not generated initially are because
splitting is requ
This patch fixes an issue whereby the compiler failed to issue an error
on the use of the attribute Result when the prefix is a non-subprogram.
Tested on x86_64-pc-linux-gnu, committed on trunk
2019-12-12 Justin Squirek
gcc/ada/
* sem_attr.adb (Analyze_Attribute): Add error message f
This patch fixes the following bug: If the Descriptor_Size attribute is
used in the private part of a generic package, then the compiler crashes
when compiling an instance of that generic.
Tested on x86_64-pc-linux-gnu, committed on trunk
2019-12-12 Bob Duff
gcc/ada/
* sem_attr.adb (
This patch fixes the following bug: If prefix notation is used to call a
subprogram, and the call is within a generic package body that is within
a package body P, and the called subprogram is not declared in the spec
of P, the compiler crashes when compiling an instance of the generic
package.
Te
Found with 'grep " \([[:alpha:]]\+\) \1[[:space:]]" *.ad?', just like in
2015; fixed manually with refilling comments where possible.
Tested on x86_64-pc-linux-gnu, committed on trunk
2019-12-12 Piotr Trojanek
gcc/ada/
* libgnat/g-altive.ads: Fix typo in comment.
* bindo-grap
This change fixes a regression that occurred on a Ravenscar test, where
gigi blew up because an itype inside the block created for a protected
entry procedure had its scope set incorrectly (designating the enclosing
package) so appeared to gigi not to be declared within the procedure.
The scope of
Compiler fails to emit a length check on the right-hand side of an
assignment when the type involved is a private type with unknown
discriminants whose full view is an unconstrained array type.
Tested on x86_64-pc-linux-gnu, committed on trunk
2019-12-12 Ed Schonberg
gcc/ada/
* exp_c
This completes the previous fix, which is not sufficient when the Size
attribute is applied to a formal object of mode In Out and the generic
is instantiated on a slice of a bit-packed array whose size is not a
multiple of the storage unit.
The hurdle here is that introducing a temporary may chang
In GNATprove flow analysis is not aware of implicitly evaluated
routines, e.g. subtype predicates and user-defined equality for record
types. Therefore SPARK 2014 mandates both routines to not reference any
globals. Likewise, we don't want them to have any effects related to
tasking, i.e. we don
For GNAT-LLVM, up-level references within the procedure created for a
protected entry were not being handled right inside the block created to
hold the declarations and statements of the entry. Calls to procedures
declared within the block that make up-level references (such as to the
init proc for
Hi,
This patch provides a fix for PR92888, wherein global variables mapped
using an OpenACC 'declare' directive would not be visible to
device-pointer lookups.
Tested with offloading to nvptx. OK?
Thanks,
Julian
ChangeLog
2019-12-12 Julian Brown
PR libgomp/92888
libgomp/
* oa
Hello.
As pointed out in the PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92591#c1, the test can be
fixed by DFA-checking more adjacent row sequences in the partial
schedule.
I've found that on powerpc64 gcc.c-torture/execute/pr61682.c test
catches same issue with -Os -fmodulo-sched-allow-
Hi,
this rather nasty bug makes value and mask to be exchanged during
streaming. This makes us to sometimes set bogus pointer alignments
and causes misoptimization of Firefox when built with GCC 9.
Comitted as obvious. I will backport it to release branches soon - it
is quite dangerous bug.
Hon
* libsupc++/compare (common_comparison_category): Define without using
concepts and optimise for compilation time.
(__detail::__cmp_cat_ids): Remove.
(__detail::__common_cmp_cat): Replace class template and
specializations with constexpr function.
Tested x86
One problem with adding an N-bit vector extension to an existing
architecture is to decide how N-bit vectors should be passed to
functions and returned from functions. Allowing all N-bit vector
types to be passed in registers breaks backwards compatibility,
since N-bit vectors could be used (and e
pass_return_slot::execute has:
/* Ignore internal functions without direct optabs,
those are expanded specially and aggregate_value_p
on their result might result in undesirable warnings
with some backends. */
&& (!gim
As Jason pointed out in the review of the C++ gnu_vector_type_p patch:
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00173.html
the real fix for the XFAILs in acle/general-c++/gnu_vectors_*.C is to
make same_type_p return false for two types if one is gnu_vector_type_p
and the other isn't. T
Though the library has limited support for x86, we don't have any
support for generating code targeting x86 so there is no point building
for that target.
libsanitizer/ChangeLog:
2019-12-12 Matthew Malcomson
* Makefile.am: Condition building hwasan directory.
* Makefile.in: Re
These flags can't be used at the same time as any of the other
sanitizers.
We add an equivalent flag to -static-libasan in -static-libhwasan to
ensure static linking.
The -fsanitize=kernel-hwaddress option is for compiling targeting the
kernel. This flag has defaults that allow compiling KASAN wi
Hello,
I've gone through the suggestions Martin made and implemented the ones I think
I can implement for GCC10.
The two functionality changes in this version are:
Added the --param's hwasan-instrument-reads, hwasan-instrument-writes,
hwasan-instrument-allocas, hwasan-memintrin, options. I.e. T
This is an analogous option to --bootstrap-asan to configure. It allows
bootstrapping GCC using HWASAN.
For the same reasons as for ASAN we have to avoid using the HWASAN
sanitizer when compiling libiberty and the lto-plugin.
Also add a function to query whether -fsanitize=hwaddress has been
pas
This patch tries to tie libhwasan into the GCC build system in the same way
that the other sanitizer runtime libraries are handled.
libsanitizer/ChangeLog:
2019-12-12 Matthew Malcomson
* Makefile.am: Build libhwasan.
* Makefile.in: Build libhwasan.
* asan/Makefile.in
Handling stack variables has three features.
1) Ensure HWASAN required alignment for stack variables
When tagging shadow memory, we need to ensure that each tag granule is
only used by one variable at a time.
This is done by ensuring that each tagged variable is aligned to the tag
granule repres
There are four main features to this change:
1) Check pointer tags match address tags.
In the new `hwasan` pass we put HWASAN_CHECK internal functions around
all memory accesses, to check that tags in the pointer being used match
the tag stored in shadow memory for the memory region being used.
Adding hwasan tests.
Only interesting thing here is that we have to make sure the tagging mechanism
is deterministic to avoid flaky tests.
gcc/testsuite/ChangeLog:
2019-12-12 Matthew Malcomson
* c-c++-common/hwasan/aligned-alloc.c: New test.
* c-c++-common/hwasan/alloca-array
On Wed, 2019-12-11 at 13:04 -0700, Jeff Law wrote:
> On Fri, 2019-11-15 at 20:23 -0500, David Malcolm wrote:
> > This patch adds exploded_graph and related classes, for managing
> > exploring paths through the user's code as a directed graph
> > of pairs.
> >
> > gcc/ChangeLog:
> > * analyzer
Document how to configure using asan (bootstrap-asan option).
Since I'm adding a bootstrap-hwasan option and documenting that,
bootstrap-asan should also be documented.
(As Martin pointed out in the hwasan reviews).
(FYI I now notice that my hwasan patch 3/X needs this to apply cleanly).
g
Updated to include documentation ChangeLog and apply cleanly on the
bootstrap-asan documentation I mentioned in a different email.
This is an analogous option to --bootstrap-asan to configure. It allows
bootstrapping GCC using HWASAN.
For the same reasons as for ASAN we have to avoid using the
On December 12, 2019 10:53:26 AM GMT+01:00, Jakub Jelinek
wrote:
>On Thu, Dec 12, 2019 at 09:22:47AM +, Richard Sandiford wrote:
>> > So there's no whole vector equality RTX but we have to pun to
>integer
>> > modes for that? The eq:SImode would suggest that. Guess we should
>have
>> > used
On December 12, 2019 4:10:33 PM GMT+01:00, Richard Sandiford
wrote:
>One problem with adding an N-bit vector extension to an existing
>architecture is to decide how N-bit vectors should be passed to
>functions and returned from functions. Allowing all N-bit vector
>types to be passed in register
Hi Srinath,
On 11/14/19 7:12 PM, Srinath Parvathaneni wrote:
Hello,
This patches series is to support Arm MVE ACLE intrinsics.
Please refer to Arm reference manual [1] and MVE intrinsics [2] for
more details.
Please refer to Chapter 13 MVE ACLE [3] for MVE intrinsics concepts.
This patch se
On Thu, Dec 12, 2019 at 04:59:40PM +0100, Richard Biener wrote:
> >If it starts being ambiguous somewhere, could we use some target macro
> >or
> >target hook to decide?
>
> Ambiguous IL is bad :/ IL semantics dependent on a target hook, too. Just
> look at SHIFT_COUNT_TRUNCATED...
The compar
On Wed, 11 Dec 2019 at 12:27, Andre Vieira (lists)
wrote:
>
> Hi,
>
> We can now vectorize an epilogue for this loop for arm too, so removing
> xfail.
>
> Is this OK for trunk? Wasn't entirely sure whether I could commit this
> under obvious.
>
This fails on armeb :-(
> gcc/testsuite/ChangeLog:
Richard Biener writes:
> On December 12, 2019 4:10:33 PM GMT+01:00, Richard Sandiford
> wrote:
>>One problem with adding an N-bit vector extension to an existing
>>architecture is to decide how N-bit vectors should be passed to
>>functions and returned from functions. Allowing all N-bit vector
Hi Matthew,
Martin is the authority on this but I have a small comment inline...
On 12/12/19 3:19 PM, Matthew Malcomson wrote:
This is an analogous option to --bootstrap-asan to configure. It allows
bootstrapping GCC using HWASAN.
For the same reasons as for ASAN we have to avoid using the HW
Hi Richard,
On 06/12/2019 10:22, Richard Sandiford wrote:
> Dennis Zhang writes:
>> 2019-12-04 Dennis Zhang
>>
>> * config/aarch64/aarch64-arches.def (armv8.6-a): New.
>> * config/aarch64/aarch64-c.c (aarch64_update_cpp_builtins): Define
>> __ARM_FEATURE_MATMUL_INT8, __ARM_FEATU
Yeah didn't test that, thanks.
This OK?
gcc/testsuite/ChangeLog:
2019-12-12 Andre Vieira
* gcc.dg/vect/vect-epilogues.c: XFAIL for arm big endian.
* lib/target-supports.exp (check_effective_target_arm_big_endian):
New target selector.
On 12/12/2019 16:42, Christoph
Applied this patchlet to add support for:
ATtiny1604, ATtiny1606, ATtiny1607, ATtiny402, ATtiny404, ATtiny406,
ATtiny804, ATtiny806, ATtiny807, ATtiny202, ATtiny204.
Johann
Add support for some more AVR devices from avrxmega3 family.
* config/avr/avr-mcus.def (attiny1604, att
On December 12, 2019 5:44:25 PM GMT+01:00, Richard Sandiford
wrote:
>Richard Biener writes:
>> On December 12, 2019 4:10:33 PM GMT+01:00, Richard Sandiford
> wrote:
>>>One problem with adding an N-bit vector extension to an existing
>>>architecture is to decide how N-bit vectors should be passed
Hi all,
On 22/11/2019 14:33, Dennis Zhang wrote:
> Hi all,
>
> This patch is part of a series adding support for Armv8.6-A features.
> It enables options including -march=armv8.6-a, +i8mm and +bf16.
> The +i8mm and +bf16 features are optional for Armv8.2-a and onward.
> Documents are at https://d
Hi Andre,
> gcc/testsuite/ChangeLog:
>
> 2019-12-12 Andre Vieira
>
> * gcc.dg/vect/vect-epilogues.c: XFAIL for arm big endian.
> * lib/target-supports.exp (check_effective_target_arm_big_endian):
> New target selector.
as always, this needs documenting in sourcebuild.te
Am 2019-12-12 10:32, schrieb Richard Sandiford:
Stefan Franke writes:
Am 2019-12-08 01:54, schrieb Oleg Endo:
On Tue, 2019-11-26 at 07:38 +0100, ste...@franke.ms wrote:
> On 11/21/19 10:30 AM, ste...@franke.ms wrote:
> > Hi there,
> >
> > here is mc68k's patch to switch the m68k architecture
Hi
With my recent commit, I added a test that is not passing on all
targets. My change was valid for targets that have a vector/scalar
shift/rotate optabs (optab that supports vector shifted by scalar).
Since it does not seem to be easy to find out which targets would
support it, I am limiting
Richard Biener writes:
> On December 12, 2019 5:44:25 PM GMT+01:00, Richard Sandiford
> wrote:
>>Richard Biener writes:
>>> On December 12, 2019 4:10:33 PM GMT+01:00, Richard Sandiford
>> wrote:
One problem with adding an N-bit vector extension to an existing
architecture is to decide h
On Thu, 2019-12-12 at 10:28 -0500, David Malcolm wrote:
> On Wed, 2019-12-11 at 13:04 -0700, Jeff Law wrote:
> > On Fri, 2019-11-15 at 20:23 -0500, David Malcolm wrote:
[...]
> > > +
> > > +
> > > //
> > > //
> > NIT. Is there some
Hello,
This is the first of a batch of changes for VxWorks, fixing
issues observed when activating libstdc++ and the associated
testing. Many of the issues are just plain bugs not (libstd)c++
specific; they are just more easily exposed in a c++ testing
context.
CC'ed Joel and Jerome on this start
Hi,
This is a fix for PR92881, broken out of the larger "reference counting
overhaul" patch last posted here:
https://gcc.gnu.org/ml/gcc-patches/2019-11/msg02235.html
The current implementation (potentially with synchronous unmapping of
a variable/memory block immediately after an asynchronous c
On 12/11/19 5:50 PM, Marek Polacek wrote:
On Fri, Nov 22, 2019 at 04:11:53PM -0500, Jason Merrill wrote:
On 11/8/19 4:24 PM, Marek Polacek wrote:
2) [class.cdtor] says that when a dynamic_cast is used in a constructor or
destructor and the operand of the dynamic_cast refers to the object unde
Hi Tobias,
> Gesendet: Donnerstag, 12. Dezember 2019 um 09:01 Uhr
> Von: "Tobias Burnus"
> An: "Harald Anlauf" , "Thomas Koenig"
> Cc: gfortran , gcc-patches
> Betreff: Re: Aw: Re: [Patch, Fortran] PR92898 - [9/10 Regression] ICE in
> gfc_check_is_contiguous, at fortran/check.c:7157
>
> Hi Har
Hello-
In the original discussion of implementing UTF-8 identifiers
( https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67224#c26 ), I pointed out
that colorization would corrupt the appearance of certain diagnostics. For
example, this code, with -std=c99:
--
int ٩x;
--
Produces:
t2.
Hi!
As the following testcase shows, for va_arg (ap, __int128) or va_arg (ap, X)
where X is __attribute__((aligned (16))) 16 byte struct containing just
integral fields we sometimes emit incorrect read. While on the stack (i.e.
the overflow area) both of these are 16-byte aligned, when __int128 o
On Thu, Dec 12, 2019 at 04:59:40PM +0100, Richard Biener wrote:
> >If it starts being ambiguous somewhere, could we use some target macro
> >or
> >target hook to decide?
>
> Ambiguous IL is bad :/ IL semantics dependent on a target hook, too. Just
> look at SHIFT_COUNT_TRUNCATED...
This is so
> Hi!
>
> As the following testcase shows, for va_arg (ap, __int128) or va_arg (ap, X)
> where X is __attribute__((aligned (16))) 16 byte struct containing just
> integral fields we sometimes emit incorrect read. While on the stack (i.e.
> the overflow area) both of these are 16-byte aligned, whe
On Wed, 2019-12-04 at 10:36 -0700, Martin Sebor wrote:
> On 11/15/19 6:22 PM, David Malcolm wrote:
> > This patch adds support for associating a diagnostic with an
> > optional
> > diagnostic_metadata object, so that plugins can add extra data to
> > their
> > diagnostics (e.g. mapping a diagnostic
Hi,
As reported in PR92926, constant ctor is shared translation unit wide because
of constexpr_call_table,
however, during gimplify, the shared ctor could be modified. This patch fixes
the issue by unsharing
it before modification in gimplify. A test is reduced from cppcoro library and
added.
Normal error-recovery.
Tested x86_64-pc-linux-gnu, applying to trunk.
* typeck.c (cp_build_binary_op): Handle error from spaceship_type.
---
gcc/cp/typeck.c | 6 +-
gcc/testsuite/g++.dg/cpp2a/spaceship-synth-neg3.C | 12
2 files changed
74 matches
Mail list logo
