I think this is good idea since it is consistent with env var
GCC_COLORS -- the color support will be disabled even with
-fdiagnostics-color=always, if GCC_COLORS is set to empty.
And I has experienced more serious problem when I ssh(1) to the remote
machine from a even older terminal, GNOME Termin
Provide a default value of $(toolexeclibdir) for $(ADA_RTL_DSO_DIR), so
that in a `--disable-libada' configuration `make install' places shared
gnatlib libraries, built with `make -C gcc gnatlib-shared', in their
intended version-specific location, fixing a commit r276424 ("libada:
Respect `--e
On Dec 20, 2019, at 8:13 AM, Olivier Hainque wrote:
>
> This change adjusts a few scan-tree-dump expressions
> to allow '$' as well as '.' when matching symbol names,
>
> Ok to commit ?
Ok.
On Dec 20, 2019, at 9:27 AM, Olivier Hainque wrote:
> gcc/testsuite/gcc.dg/cpp/ucs.c #include
> and then crafts a definition of WCHAR_MAX depending
> on __WCHAR_TYPE__.
> Ok to commit ?
Ok.
On Dec 20, 2019, at 10:11 AM, Olivier Hainque wrote:
>
> The attached patch is a proposal for a basic solution
> to an issue which might be an improper thing done by a
> system header on VxWorks, but which is a big pain to fix
> at this level and very simple to address super locally.
> Is this O
On Dec 9, 2019, at 1:30 PM, Maciej W. Rozycki wrote:
>
> On Fri, 29 Nov 2019, Maciej W. Rozycki wrote:
>
>> Fix a catastrophic libgo testsuite failure in cross-compilation where
>> the shared `libgcc_s' library cannot be found by the loader at run time
>> in build-tree testing and consequently
On Dec 16, 2019, at 4:06 PM, Maciej W. Rozycki wrote:
>
> On Mon, 11 Nov 2019, Maciej W. Rozycki wrote:
>
>> This patch series addresses a problem with the testsuite compiler being
>> set up across libatomic, libffi, libgo, libgomp with no correlation
>> whatsoever to the target compiler being
These are new tests. They verify if you are doing a vec_extract of a vector in
memory and the vector's address contains a large offset and the element number
is constant, it generates a prefixed load instruction when -mcpu=future.
Once all of the other V11 patches are checked in, can I check this
These tests are new. These tests check that the vector extract from a vector
in memory works correctly for both constant and variable element numbers.
These tests pass with all of the previoius pataches applied. Can I check these
patches into the trunk?
2019-12-20 Michael Meissner
*
This is patch V8 #6. It makes sure the stack protect insns work when
-mcpu=future and -fstack-protector-strong are used together. We discovered
this failure when we attempted to build GLIBC using -mcpu=future.
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00089.html
This test now passes when I r
This patch fixes an issue with the output of -fdump-analyzer-supergraph
on BBs with no statements, where the resulting files were unreadable by
dot e.g.:
Error: syntax error in line 1
... ...
in label of node node_10
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to the dm
This is a reworking of patch V8 #5. It adds a bunch of PC-relative tests for
the -mcpu=future target.
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00085.html
This test passes when I run it. Can I check it in?
2019-12-20 Michael Meissner
* gcc.target/powerpc/prefix-pcrel.h: New set
This is a reworking of the tests I submitted previously in V8 #4. It generates
a bunch of loads and stores for various types using large addresses, and
verifies that the number of prefixed loads and stores is correct.
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00084.html
This patch works when
This is V10 patch #12. It adds a test to make sure we don't generate a
prefixed instruction with PRE_INC, PRE_DEC, or PRE_MODIFY.
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00846.html
This test passes when I run it. Can I check this into the trunk?
2019-12-20 Michael Meissner
* g
On Fri, Dec 20, 2019 at 06:18:04PM -0500, Jason Merrill wrote:
> > BTW, is the testcase valid in C++17 mode? GCC 7/8/9/trunk accept it,
> > but clang++ rejects it.
>
> No, non-template parameters of class types are a C++20 feature.
Trunk accepts it since r276248 aka PR91923 in -std=c++17 mode.
This is V10 patch #11. This adds a new test to validate that for -mcpu=future,
we generate a prefixed load/store if the offset would have been illegal for a
non-prefixed DS or DQ instruction.
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00845.html
This test passes when I run the testsuite. Can
This is V10 patch #10. It adds 3 new tests to verify that we generate PADDI/PLI
for large constants when -mcpu=future is used.
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00843.html
This test passes when the preceeding patches are applied. Can I check this in?
2019-12-20 Michael Meissner
This is V10 patch #9. It adds new target_supports tests for the new patches:
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00842.html
All of the new tests work with these target supports. Can I check it into the
trunk?
2019-12-20 Michael Meissner
* lib/target-supports.exp (check_eff
This is the same as V10 patch #8. Once the vector extract patches are
committed, this patch flips the default to use PC-relative addressing on 64-bit
Linux systems when the uses -mcpu=future.
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00841.html
I have bootstrapped the compiler on a little end
On Sun, Dec 15, 2019 at 07:11:25PM +0100, Thomas Koenig wrote:
> Am 10.12.19 um 22:22 schrieb Thomas Koenig:
> > Steve made an excellent suggestion: -finline-arg-packing .
> >
> > So, OK with that change?
>
> In other words, is
>
> https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00485.html
>
> OK
This patch recognizes when we are doing the optimization of vector extract with
a constant element number when the vector is in memory and the vector's address
is PC-relative, to directly re-form the address using a PC-relative load,
instead of loading the address into a temporary register, and the
In doing V11 patch #3, I noticed that the documentation for the 'Q' was
misleading. This patch updates the documentation. Can I check this patch into
the trunk?
2019-12-20 Michael Meissner
* config/rs6000/constraints.md (Q constraint): Update
documentation.
* doc/md.t
As I mentioned in the intro, for the case where we are optimizing the extract
of a variable element from a vector in memory, the current code takes a regular
address, and the temporary that holds the byte offset, and tries to generate a
new address. In particular, it failed when the vector was a P
This patch incorporates large offsets for -mcpu=future when we optimization a
vector extract from memory and the memory address previously had been a
prefixed address with a large offset.
The current code would generate loading up the constant into a temporary and
then doing an indexed load. Succ
Hi!
As mentioned in the PR, the following testcase is miscompiled with avx512vl.
The reason is that the fma *_bcst_1 define_insns have two alternatives:
"=v,v" "0,v" "v,0" "m,m" and use the same
vfmadd213* %3, %2, %0
pattern. If the first alternative is chosen, everything is ok, but if the
second
Hi!
In C++17/2a mode, cp_parser_constructor_declarator_p because of deduction
guides considers constructor_p in more cases and returns true on
typedef struct S { int x; } T;
T (__attribute__((unused)) qux) (T x);
just because constructor arguments may start with __attribute__ keyword
(as the testc
This patch fixes the bug pointed out in the V10 patch review that the code
modified an input argument to vector extract with a variable element number.
I also added two gcc_asserts to the vector extract address code to signal an
internal error if the temporary base register was used for two differ
On Fri, Dec 20, 2019 at 05:56:39PM -0500, Jason Merrill wrote:
> On 12/20/19 3:27 PM, Marek Polacek wrote:
> > In r268428 I changed reshape_init_r in such a way that when it sees
> > a nested { } in a CONSTRUCTOR with missing braces, it just returns
> > the initializer:
> > + else if (COMPOUND_
On 12/17/19 3:51 PM, Jakub Jelinek wrote:
Hi!
On the following testcase, complain & tf_error is 0 during sfinae, so we
don't emit error, but we called structural_type_p with explain=true anyway,
which emitted the inform messages.
Fixed by doing it only when we emit the error.
Bootstrapped/regte
On 12/17/19 3:57 PM, Jakub Jelinek wrote:
Hi!
When the prototype of defaulted comparison operator is incorrect, we set
DECL_MAYBE_DELETED, but don't set DECL_DEFAULTED_FN and other flags, so we
ICE during synthetize_method.
Seems only marking DECL_MAYBE_DELETED those operators that we are also
This set of patches reworks the vector extract issues in the V10 patches.
If you recall, in V10, you pointed out that for vector extract, the existing
code overwrote an input argument, and that is fixed in these patches.
In V10, I added two new constraints (ep and em) to categorize whether a memo
On 12/17/19 3:59 PM, Jakub Jelinek wrote:
Hi!
As discussed on IRC, defaulted comparison operators were added only in
C++2a, so we shouldn't accept it in older standard modes.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
OK.
2019-12-17 Jakub Jelinek
PR c++
On 12/18/19 6:44 PM, Jakub Jelinek wrote:
Hi!
convert_arg_to_ellipsis used to call decay_conversion for all types
(which calls mark_rvalue_use), but it doesn't anymore in GCC 10,
and while for INTEGRAL_OR_ENUMERATION_TYPE_P args it calls
cp_perform_integral_promotions which does that too and for
On 12/19/19 11:33 AM, Richard Sandiford wrote:
This test:
typedef unsigned int v4si __attribute__ ((vector_size(16)));
typedef unsigned char v16qi __attribute__ ((vector_size(16)));
extern v16qi x;
v4si &y = x;
ICEs with:
a.c:4:11: internal compiler error: in convert_like_real, at cp/call.c:76
On 12/18/19 6:40 PM, Jakub Jelinek wrote:
Hi!
While looking at PR92666, I've spotted a wrong-code issue where we ignore
any side-effects on arguments passed to ellipsis if they have
decltype(nullptr) type.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk and rel
On 12/20/19 3:27 PM, Marek Polacek wrote:
In r268428 I changed reshape_init_r in such a way that when it sees
a nested { } in a CONSTRUCTOR with missing braces, it just returns
the initializer:
+ else if (COMPOUND_LITERAL_P (stripped_init)
...
+ ++d->cur;
+ gcc_assert (!BRACE_
On 12/19/19 6:05 PM, Marek Polacek wrote:
build_min_non_dep wasn't setting any location so when we were emitting the
warning in the following test while instantiating a template, it's location
was UNKNOWN_LOCATION. Rather than adding a location_t parameter, let's use
the location from the origin
On 12/20/19 3:27 PM, Marek Polacek wrote:
In r268428 I changed reshape_init_r in such a way that when it sees
a nested { } in a CONSTRUCTOR with missing braces, it just returns
the initializer:
+ else if (COMPOUND_LITERAL_P (stripped_init)
...
+ ++d->cur;
+ gcc_assert (!BRACE_
The fix for PR70853 changed an ICE-on-invalid for NULLIFY into a
misleading error message. The patch below rectifies that.
OK for trunk?
Regtested on x86_64-pc-linux-gnu.
Thanks,
Harald
Index: gcc/fortran/match.c
===
--- gcc/fortr
In r268428 I changed reshape_init_r in such a way that when it sees
a nested { } in a CONSTRUCTOR with missing braces, it just returns
the initializer:
+ else if (COMPOUND_LITERAL_P (stripped_init)
...
+ ++d->cur;
+ gcc_assert (!BRACE_ENCLOSED_INITIALIZER_P (stripped_init));
+
In the reproducer for PR analyzer/58237 I noticed that some events were
missing locations (and text); for example event 3 here:
| 15 | while (fgets(buf, 10, fp) != NULL)
| | ~
| | |
| | (2) following 'false' branch...
|
'f1': event 3
In the reproducer for PR analyzer/58237 I noticed that some events that
were missing locations were also missing text; for example event 3 here:
| 15 | while (fgets(buf, 10, fp) != NULL)
| | ~
| | |
| | (2) following 'false' branch...
This patch adds the ARMv8.6 ACLE BFloat16 load intrinsics vld{q}_bf16
as part of the BFloat16 extension.
(https://developer.arm.com/architectures/instruction-sets/simd-isas/neon/intrinsics)
The intrinsics are declared in arm_neon.h .
A new test is added to check assembler output.
This patch depen
This patch adds the ARMv8.6 ACLE BFloat16 store intrinsics
vst{q}_bf16 as part of the BFloat16 extension.
(https://developer.arm.com/architectures/instruction-sets/simd-isas/neon/intrinsics)
The intrinsics are declared in arm_neon.h .
A new test is added to check assembler output.
This patch depe
This patch adds the ARMv8.6 ACLE intrinsics for vmmla, vfmab and vfmat
as part of the BFloat16 extension.
(https://developer.arm.com/docs/101028/latest.)
The intrinsics are declared in arm_neon.h and the RTL patterns are
defined in neon.md.
Two new tests are added to check assembler output and la
This patch adds the Armv8.6-a ACLE intrinsics for bfmmla, bfmlalb and
bfmlalt as part of the BFloat16 extension.
(https://developer.arm.com/architectures/instruction-sets/simd-isas/neon/intrinsics)
The intrinsics are declared in arm_bf16.h and arm_neon.h and the RTL
patterns are defined in aarch6
This patch adds the ARMv8.6 ACLE intrinsics for bfmmla, bfmlalb and
bfmlalt as part of the BFloat16 extension.
(https://developer.arm.com/architectures/instruction-sets/simd-isas/neon/intrinsics)
The intrinsics are declared in arm_neon.h and the RTL patterns are
defined in aarch64-simd.md.
Two ne
On 12/20/19 9:35 AM, Segher Boessenkool wrote:
> Something automated to verify what we implement is what we have documented
> would be neat to have. Maybe this becomes feasible with the rewrite of
> the builtin stuff :-)
Agreed!
>> This passed bootstrap and regression testing with no errors.
Hello,
The attached patch is a proposal for a basic solution
to an issue which might be an improper thing done by a
system header on VxWorks, but which is a big pain to fix
at this level and very simple to address super locally.
A number of tests based on gcc.dg/vect/tree-vect.h
#define and then
Hi!
I've backported following 25 patches from trunk to 9.x,
bootstrapped/regtested on x86_64-linux and i686-linux, committed
to gcc-9-branch.
Jakub
2019-12-20 Jakub Jelinek
Backported from mainline
2019-11-21 Jakub Jelinek
Jason Merrill
This fixes the following discrepancy: when a C or C++ file contains no
translation unit but only preprocessor macro definitions, -fdump-ada-spec
outputs nothing but -fdump-ada-spec-slim does. This changes the former to
behaving as the latter in this case.
Tested on x86_64-suse-linux, applied o
Hi!
On Fri, Dec 20, 2019 at 02:34:05PM +0800, Jiufu Guo wrote:
> Previously, limited unrolling was enabled at O2 for powerpc in r278034. At
> that
> time, -fweb and -frename-registers were not enabled together with
> -funroll-loops
> even for -O3. After that, we notice there are some performan
Hello,
gcc/testsuite/gcc.dg/cpp/ucs.c #include
and then crafts a definition of WCHAR_MAX depending
on __WCHAR_TYPE__.
The test fails in VxWorks configurations because WCHAR_MAX
is already exposed by the system limits.h.
The attached patch simply guards the tentative definition
by a check verify
On 19/12/19 09:36 +, Jonathan Wakely wrote:
On 05/12/19 17:12 +0100, Christophe Lyon wrote:
On Thu, 5 Dec 2019 at 12:43, Jonathan Wakely wrote:
On 05/12/19 09:00 +0100, Christophe Lyon wrote:
On Tue, 3 Dec 2019 at 10:16, Jonathan Wakely wrote:
On 03/12/19 09:11 +0100, Christophe Lyon
Hi Thomas,
thanks for the review! I have attached a revised patch.
> > There is no AMD GCN support yet. This will be added later on.
>
> ACK, just to note that there now is a 'libgomp/plugin/plugin-gcn.c' that
> at least needs to get a stub implementation (can mostly copy from
> 'libgomp/plugin/pl
Hi!
On Wed, Dec 18, 2019 at 05:15:21PM -0500, Michael Meissner wrote:
> In the patch:
> https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01201.html
>
> Segher Boessenkool asked me to submit a patch to rename the macros used to see
> if a number is a valid signed 16 or 34-bit value:
>
> > Please fol
Hi,
more of the last idea, this time applied to cp_parser_delete_expression
/ delete_sanity (thus build_delete and build_vec_delete which provide
tests). Nothing particularly remarkable in this case. Tested x86_64-linux.
Thanks, Paolo.
///
/gcc/cp
2019-12-20 Pao
The testcase was originally committed with an incorrect changelog and PR
number. The changelog was fixed later, but not the comment in the test.
PR fortran/69497
* gfortran.dg/pr69497.f90: Fix PR number in comment.
I'm going to commit this to trunk as obvious.
commit 1c52a87af8a
Hello,
This change adjusts a few scan-tree-dump expressions
to allow '$' as well as '.' when matching symbol names,
This improves results on VxWorks targets configured with:
#undef NO_DOLLAR_IN_LABEL
#define NO_DOT_IN_LABEL
Bootstrapped and regression tested fine on x86_64-linux-gnu.
Ok to
Hi!
On Tue, Dec 17, 2019 at 07:06:19PM -0600, Peter Bergner wrote:
> PR92923 shows a problem where builtin function usage is causing performance
> problems due to unneeded subreg usage. These are being caused by the front-
> end emitting unneeded VIEW_CONVERT_EXPR's on the builtin functions opera
Hi Dennis,
On 12/12/19 5:30 PM, Dennis Zhang wrote:
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
Hi,
PR 93015 testcase - an empty main function compiled with -O0 -fipa-vrp
-flto - shows that IPA-VRA can segfault when trying to access results of
an analysis that has not been performed because of zero optimization
level, -fno-ipa-cp etc.
Rather than adding another chain of opt_for_fn() the pat
the attached patch fixes an ICE in an array declaration where the
specified size came from 0/0. This is an 8/9/10 regression.
Actually, it does not fix all testcases in the PR, so some more
tweaking is still needed.
Regards
Thomas
On 16/12/19 14:51 +0100, Jérôme Lambourg wrote:
Hello,
In libstdc++, the test for the presence of setrlimit on the target is currently
performed in C as opposed to the other similar tests there. This leads on only a
warning being issued during configure as opposed to the expected error, and thus
Stam Markianos-Wright writes:
> Hi all,
>
> This patch adds the ARMv8.6 Extension ACLE intrinsics for the bfloat bfdot
> operation.
>
> The functions are declared in arm_neon.h with the armv8.2-a+bf16 target
> option
> as required.
>
> RTL patterns are defined to generate assembler.
>
> Tests a
Hi all,
This patch was developed at the same time as the aarch64 version. Richards'
feedback on that one also applies here and we'll be addressing them in a respin.
However, it's still useful to get this up for everyone (including ARM
maintainers) to look and and comment, too.
For reference ,
Hi, I just saw this:
FAIL: gfortran.dg/goacc/finalize-1.f -O scan-tree-dump-times gimple
"(?n)#pragma omp target oacc_enter_exit_data
map\\(delete:MEM\\[\\(c_char \\*\\)[^\\]]+\\] \\[len: [^\\]]+\\]\\)
map\\(to:del_f_p \\[pointer set, len: [0-9]+\\]\\)
map\\(alloc:del_f_p\\.data \\[pointe
Hello world,
the attached patch fixes an ICE in an array declaration where the
specified size came from 0/0. This is an 8/9/10 regression.
The actual ICE fix was the NULL check in simplify_intrinsic_op, which in
turn led to strange error messages, which are then corrected by
the rest of the patc
Stam Markianos-Wright writes:
> diff --git a/gcc/config/aarch64/aarch64-simd.md
> b/gcc/config/aarch64/aarch64-simd.md
> index
> ad4676bc167f08951e693916c7ef796e3501762a..eba71f004ef67af654f9c512b720aa6cfdd1d7fc
> 100644
> --- a/gcc/config/aarch64/aarch64-simd.md
> +++ b/gcc/config/aarch64/aarc
Hi all,
This patch adds the ARMv8.6 Extension ACLE intrinsics for the bfloat bfdot
operation.
The functions are declared in arm_neon.h with the armv8.2-a+bf16 target option
as required.
RTL patterns are defined to generate assembler.
Tests added to verify expected assembly and perform adequat
On 12/18/19 4:47 PM, Richard Sandiford wrote:
> Stam Markianos-Wright writes:
>> On 12/13/19 11:15 AM, Richard Sandiford wrote:
>>> Stam Markianos-Wright writes:
Hi all,
This small patch adds support for the ARM v8.6 extensions +bf16 and
+i8mm to the testsuite. This will be
On 12/13/19 11:02 AM, Richard Sandiford wrote:
> Stam Markianos-Wright writes:
>> @@ -573,6 +586,44 @@
>> [(set_attr "type" "neon_dot")]
>> )
>>
>> +;; These instructions map to the __builtins for the armv8.6a I8MM usdot,
>> sudot
>> +;; (by element) Dot Product operations.
>> +(define
Comitted as trivial.
After this I only have 1 failure left specific to versioned namespace in
pretty printers tests.
* testsuite/23_containers/map/48101_neg.cc: Add versioned namespace
pattern to tested error message.
* testsuite/23_containers/multimap/48101_neg.cc: Likewise.
*
Hi Julian,
thanks for the patch and the post-review fixes. (The revised patch was
committed as r279628. And I have committed a few minor follow-up
improvements.)
I still have an issues with the following.
On 12/18/19 11:51 PM, Tobias Burnus wrote:
+ /* Disallow duplicate bare variable
Julian has committed that patch as Rev. 279628.
Follow up regarding coarrays:
I had proposed to use 'gfc_is_coindexed' instead of only checking the
rightmost array reference. However, it turned out that this check comes
too late. (As did the check before Julian's patch.)
Namely, when checkin
Hi Tobias,
One has the choice between
(a) Using the location where the expression was defined (in the
scoping unit) – currently done
(i.e. replacing expr->where by expr->symtree->n.sym->where)
(b) using the location where the parameter is used, i.e. keeping
expr->where despite sim
Add myself to MAINTAINERS file
2019-12-20 Jerome Lambourg
* MAINTAINERS: Add myself to Write After Approval
maintainers.patch
Description: Binary data
On 13/12/19 22:27 +0100, François Dumont wrote:
Here is a patch to fix prettyprinters.exp failures in normal and debug
modes.
In 80276.cc I replicate the #define with comment from other tests even
if it isn't true that cxx11 abi string isn't supported. It's just that
it doesn't appear as 'std
On 10/12/19 15:58 +0100, Corentin Gay wrote:
Hello there !
When implementing the support for gthreads in VxWorks, we stumbled on a
problem in the testsuite. In the libstdc++ testsuite, we
indiscriminately add the `-pthread` switch to the tests that require
linking against the pthread library.
> Can you please be a little more specific as to what kind of breakage you
> see and/or specific configuration options and steps required to reproduce
> it?
/usr/bin/install: missing destination file operand after 'rts/libgnat-21.so'
Try '/usr/bin/install --help' for more information.
ln: failed
Julian's patch (r279628) removed several now obsolete dg-errors about
ALLOCATABLE and POINTER.
But seemingly, one was missed and two (for no_create) were added between
posting the patch and committing that patch.
Committed the attached patch as obvious in Rev.279634.
Cheers,
Tobias
Index:
Hi Steve,
On 12/20/19 1:26 AM, Steve Kargl wrote:
On Thu, Dec 19, 2019 at 09:30:49PM +0100, Tobias Burnus wrote:
The latter could be "solved" by using %C instead of %L after
gfc_simplify_expr in gfc_match_stopcode.
[The "ref" has its own address (e->ref->u.ar->where); hence,
the a(1,1) error wo
82 matches
Mail list logo
