gcc.dg/torture/pr91323.c tests that a compare with NaNf doesn't set an
exception using builtin compare intrinsics, and that it does when
using regular compare operators.
That doesn't seem to be expected to work on powerpc targets. It fails
on GNU/Linux, it's marked to be skipped on AIX, and a s
The loop we're supposed to try to vectorize in
gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c is turned into a memset
before the vectorizer runs.
Various other tests in this set have already run into this, and the
solution has been to disable this loop distribution transformation,
enabled at -O2
This test expects vectorization at power8+ because strict alignment is
not required for vectors. For power7, vectorization is not to take
place because it's not deemed profitable: 12 iterations would be
required to make it so.
But for power6 and below, the test's 10 iterations are enough to mak
Hi,
On 08.03.21 17:25, Eric Botcazou wrote:
AFAICS the code in build_round_expr implicitly assumes that __float128 exists,
which is *not* the common case among 64-bit architectures since "long double"
is generally already 128-bit for them.
Crossref: Introduced by the Patch for PR96711,
https:
Dear Harald, dear all,
On 09.03.21 20:45, Harald Anlauf via Fortran wrote:
character variables with undefined length are not allowed as
objects in DATA statements. We better reject them.
Regtested on x86_64-pc-linux-gnu. OK for master / backport?
PR fortran/99205 - Out of memory with undefin
On 19/02/2021 15:05, Vladimir Makarov wrote:
On 2021-02-19 5:53 a.m., Andre Vieira (lists) wrote:
Hi,
This patch makes sure that allocno copies are not created for
unordered modes. The testcases in the PR highlighted a case where an
allocno copy was being created for:
(insn 121 120 123 11
Belated follow-up to the patch from August ...
https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552588.html
This patch handles CLASS variables in the FIRSTPRIVATE data-sharing
clause, including freeing the memory at the end.
Technically this patch fixes a regression as the ICE is new –
befo
We've observed failures of this test on powerpc configurations that
default to different calling conventions and alignment requirements.
Both settings are needed for the expectations to be met.
This was regstrapped on x86_64-linux-gnu and ppc64-linux-gnu, and tested
with a cross to a ppc64-vxwor
The fix for PR94775 added more strict checking for type reuse
to check_aligned_type, specifically matching TYPE_USER_ALIGN.
But then build_aligned_type sets TYPE_USER_ALIGN on the built
variant so if the type we build an aligned variant for does not
have TYPE_USER_ALIGN we'll never re-use the newly
Most (all?) powerpc tests that use the __float128 type either enable
it with -mfloat128, or use effective target requirements to check for
its presence.
prefix-ds-dq.c is failing in some of our configurations because it
uses the __float128 type without checking for it, or enabling it
explicitly.
libstdc++-v3/ChangeLog:
* testsuite/std/time/syn_c++20.cc: Enable synopsis checks for
C++20 calendar types.
Tested x86_64-linux. Committed to trunk.
commit e7afb82c358855510aa90ae9869663b614a732cb
Author: Jonathan Wakely
Date: Wed Mar 10 11:14:17 2021
libstdc++: Uncomment
The gcc man page currently has untranslated @tie{} patterns in the man page.
Just replace these with a white space. Ok for the trunk and branches?
Matthias
--- a/contrib/texi2pod.pl
+++ b/contrib/texi2pod.pl
@@ -210,6 +210,7 @@ while(<$inf>) {
s/\@TeX\{\}/TeX/g;
s/\@pounds\{\}/\#/g;
> I think it is a bad idea to hard-code the real type.
> Does the following work for you? If so, I think that
> patch is obvious and you can go ahead and commit it.
>
> --- a/gcc/fortran/trans-intrinsic.c
> +++ b/gcc/fortran/trans-intrinsic.c
> @@ -407,7 +407,7 @@ build_round_expr (tree arg, tree
Returning a REGMODE_NATURAL_SIZE of 4 for DFmode in 64-bit mode is asking for
trouble because sub-word SUBREGs are always treated differently than the
others, in particular by the register allocator.
Bootstrapped/regtested on SPARC64/Linux and SPARC/Solaris, applied on the
mainline.
2021-03-1
This is a strange regression present on the mainline and 10 branch, whereby an
enumeration type declared as atomic (or volatile) incorrectly triggers the ODR
machinery for its values in LTO mode.
Tested on x86-64/Linux, applied on the mainline and 10 branch.
2021-03-10 Eric Botcazou
Hi all,
This patch fixes PR99102. For masked gather loads/scatter stores the
'loop_masks' variable was checked to be non-null, but the 'final_mask' was the
actual mask used.
bootstrapped and regression tested on aarch64. Regression tested on aarch64_sve
under qemu.
[Vect] Fix mask check on Scat
On Wed, 10 Mar 2021, Joel Hutton wrote:
> Hi all,
>
> This patch fixes PR99102. For masked gather loads/scatter stores the
> 'loop_masks' variable was checked to be non-null, but the 'final_mask' was the
> actual mask used.
>
> bootstrapped and regression tested on aarch64. Regression tested on
Joel Hutton writes:
> Hi all,
>
> This patch fixes PR99102. For masked gather loads/scatter stores the
> 'loop_masks' variable was checked to be non-null, but the 'final_mask' was the
> actual mask used.
>
> bootstrapped and regression tested on aarch64. Regression tested on
> aarch64_sve
> under
On Tue, Mar 9, 2021 at 9:57 PM Ivan Sučić wrote:
>
> Richard Biener wrote:
> >I don't think removing all code is OK since it would
> >allow combining x == y || x > y to x >= y which may
> >trap. The bugreport suggests to alter the last
> >test to something like
> >
> > if (trap && !ltrap && !rtra
>> gcc/testsuite/ChangeLog:
>>
>> PR target/99102
>> * gcc.target/aarch64/sve/pr99102.c: New test.
>
>(The filename is out of date, but the git hook would catch that.)
Fixed and committed.
>
>>
>> diff --git a/gcc/testsuite/gcc.dg/vect/pr99102.c
>> b/gcc/testsuite/gcc.dg/vect/pr99102.c
>> new
Joel Hutton writes:
>>> gcc/testsuite/ChangeLog:
>>>
>>> PR target/99102
>>> * gcc.target/aarch64/sve/pr99102.c: New test.
>>
>>(The filename is out of date, but the git hook would catch that.)
> Fixed and committed.
>
>>
>>>
>>> diff --git a/gcc/testsuite/gcc.dg/vect/pr99102.c
>>> b/gcc/test
A couple of analyzer testcases no longer have state explosions; updating
them accordingly in case they regress.
Successfully regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as 46b52b4ae118e4d682beb0bef4f51396cd40ebfe.
gcc/testsuite/ChangeLog:
* gcc.dg/analyzer/pr94047.c: Remove "-Wno-a
Implement dyn_cast_callgraph_superedge once in callgraph_superedge,
rather than twice in the two subclasses.
Spotted whilst working on a patch for call summaries.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as c84faa9b7bb0f98ba15a8e29d21232243676d54d.
gcc/analy
On 2021-03-10 5:25 a.m., Andre Vieira (lists) wrote:
On 19/02/2021 15:05, Vladimir Makarov wrote:
On 2021-02-19 5:53 a.m., Andre Vieira (lists) wrote:
Hi,
This patch makes sure that allocno copies are not created for
unordered modes. The testcases in the PR highlighted a case where an
al
The C/C++ FE sets for an 'omp declare target' ... 'omp end declare target'
the attribute 'omp declare target implicit'.
That's later processed (for C++) in decl.c - which remove that attribute
and either keeps and explicit 'omp declare target' or 'omp declare target link'
attribute.
Unfortunatel
If a variable appears in DATA, the following applies:
F2018: 8.6.7 DATA statement
"Except for variables in named common blocks, a named variable has the
SAVE attribute if any part of it is initialized in a DATA statement,
and this may be confirmed by explicit specification."
The attached test
Hi all,
This patch adds the recently-added tweak to split some SVE VL-based scalar
operations [1] to the generic tuning used for SVE, as enabled by adding +sve
to the -march flag, for example -march=armv8.2-a+sve.
The recommendation for best performance on a particular CPU remains unchanged:
use
Please disregard this v2 patch. V1 is the correct patch.
Change log entries to be added for V1, to follow.
Richard
> -Original Message-
> From: Richard Wai
> Sent: March 9, 2021 4:26 PM
> To: 'Arnaud Charlet'
> Cc: 'gcc-patches@gcc.gnu.org' ; 'Bob Duff'
>
> Subject: [PATCH v2] Ada: ha
Arno,
I appologise for making a mess of this final step. I have leared the errors
of my ways.
Below are the change log entries for this patch:
gcc/ada/Changelog:
2021-03-09 Richard Wai
* libgnat/a-cohase.ads (Cursor): Synchronize comments for the Cursor
type definition to be
This patch fixes a typo in the description of
aarch64_vfp_is_call_or_return_candidate.
Committed as obvious.
Thanks,
Alex
gcc/ChangeLog:
* config/aarch64/aarch64.c (aarch64_vfp_is_call_or_return_candidate):
Fix typo in comment describing "is_ha" argument.
diff --git a/gcc/config
> I appologise for making a mess of this final step. I have leared the errors
> of my ways.
Can you please submit everything self contained (the final final code changes
along with the commit log) so that we are sure the proper patch is
reviewed and approved?
> Below are the change log entries fo
The proposed resolution for this library issue simplifies the
constraints for compare_three_way, ranges::equal_to, ranges::less etc.
so that they do not work with types which are convertible to pointers
but which fail to meet the usual syntactic requirements for the
comparisons.
This affects the e
This adds missing includes to internal library headers which get
included from more than one other header, so that they can be compiled
as a stand-alone header unit.
For existing use cases these includes are no-ops because they're already
done by the header that includes these files. For compiling
This is another place where our one-true-decl representation breaks
down. The fix here propagates the assembly name to the ns-scope alias.
that fixes the reported problem but changes the behaviour when the user
has explicitly declared the entity in its namespace. However, we didn't
handle t
> -Original Message-
> From: Arnaud Charlet
> Sent: March 10, 2021 10:23 AM
> To: Richard Wai
> Cc: gcc-patches@gcc.gnu.org; 'Bob Duff' ; Arnaud
> Charlet
> Subject: Re: [PATCH] Ada: hashed container Cursor type predefined equality
> non-conformance
>
> > I appologise for making a mess
This change fixes various tests that need linking against libatomic on hppa.
Committed to trunk.
Dave
--
John David Anglin dave.ang...@bell.net
Add options to link with libatomic in various tests.
libstdc++-v3/ChangeLog:
* testsuite/29_atomics/atomic/wait_notify/bool.cc: Add options
The new pr99305.C testcase is failing on Power.
FAIL: g++.dg/opt/pr99305.C -std=gnu++14 scan-tree-dump-times
optimized " = (unsigned char) c_[0-9]*(D);" 3
FAIL: g++.dg/opt/pr99305.C -std=gnu++17 scan-tree-dump-times
optimized " = (unsigned char) c_[0-9]*(D);" 3
> I'm not sure I correctly understand you here, but my interpretation is that
> I should no longer submit Changelog entries, rather just the patch, and then
Right.
> a commit message (a-la git), and then presumably the Changelong entries will
> be generated automatically. From what I can see, gcc
> And the commit log will look like:
>
> 2021-03-09 Richard Wai
>
> gcc/ada/
> * libgnat/...
>
> gcc/testsuite/
> * gnat.dg/containers2.adb: ...
>
> Your patch is OK with these changes, thanks.
Understood! Thanks for that.
Richard
Hi!
On unsigned_char targets, the cast stmt to unsigned char is obviously
not needed (and shouldn't be there). But it doesn't hurt to test
the rest also on targets where char is unsigned.
Tested on x86_64-linux and with cross to powerpc64le-linux, committed
to trunk.
2021-03-10 Jakub Jelinek
Ping patch.
| Subject: [PATCH, V3] Require GLIBC 2.32 for Decimal/_Float128 conversions.
| Message-ID: <20210304210135.ga32...@ibm-toto.the-meissners.org>
--
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-47
Ping patch.
| Subject: [PATCH V3] Do not build Decimal/Float128 conversions if
--disable-decimal-float.
| Message-ID: <20210304210803.ga...@ibm-toto.the-meissners.org>
--
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +
On 3/9/21 6:46 PM, David Lamparter wrote:
On Wed, Mar 10, 2021 at 02:28:15AM +0100, David Lamparter wrote:
The TYPE_MAIN_VARIANT() here was, for casts to a typedef'd type name,
resulting in all information about the typedef's involvement getting
lost. This drops necessary information for warnin
As preparatory work for a fix to PR analyzer/96374, this patch
moves the core state-update logic from the loop in
exploded_path::feasible_p into a new class feasibility_state.
No functional change intended.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r11-7609
On Wed, 10 Mar 2021, Alexandre Oliva wrote:
>
> The test expects shrink-wrapping of the fsqrt call, but that will only
> occur when there is a usable sqrt insn.
>
> Arrange for dejagnu to add the options that enable the sqrt insn, if
> one is available, and to skip the test otherwise.
>
>
> H-P, t
On 10/03/21 11:08 -0500, John David Anglin wrote:
This change fixes various tests that need linking against libatomic on hppa.
Committed to trunk.
Thanks.
diff --git a/libstdc++-v3/testsuite/30_threads/latch/3.cc
b/libstdc++-v3/testsuite/30_threads/latch/3.cc
index 079963f131e..2da6a84e2c5
On 2021-03-10 12:36 p.m., Jonathan Wakely wrote:
> Most of this looks good but I think we'll want to remove it from this
> test again, as we're about to change the atomic type from ptrdiff_t to
> int, and so hppa won't need libatomic.
That would be good.
--
John David Anglin dave.ang...@bell.net
On Wed, Mar 10, 2021 at 10:01:39AM -0700, Martin Sebor wrote:
> On 3/9/21 6:46 PM, David Lamparter wrote:
> > On Wed, Mar 10, 2021 at 02:28:15AM +0100, David Lamparter wrote:
> >> The TYPE_MAIN_VARIANT() here was, for casts to a typedef'd type name,
> >> resulting in all information about the typed
On Wed, Mar 10, 2021 at 08:02:16PM +0100, David Lamparter wrote:
> Also, in seeing your response re. the volatile, it occured to me that
> stripping qualifiers on a typedef and still calling it the typedef is
> unhelpful. Ideally, my goal is:
>
> typedef int i;
> typedef const int ci;
> typeof((i
Dear Tobias,
thanks for your comments.
> > A variable that is a data statement object shall be a designator,
> > thus a character variable shall have a constant length.
>
> This comment is wrong: A designator does not imply this – nor is
> F2018:C875 violated, not even the substring starting/end
My reworking of pending-entity loading introduced a GC problem. The
post-load processing needs to inhibit GCs (that would otherwise occur in
clone_decl). That wasn't happening on one code path, leading to
dangling pointers in the active call frames.
PR c++/99423
gcc/cp/
Dear Harald,
On 10.03.21 20:43, Harald Anlauf wrote:
In the following variant of the program, the invalid
variable declaration of 'c' itself is avoided by using
a block:
integer :: ll
ll = 4
block
character(ll) :: c(2), cc(2)
character(ll) :: c2(2), cc2(2)
data c /'a', 'b'/
data
It needs the int128 selector because it uses __int128, and the lp64
selector is the best we can do for -mcmodel=.
2021-03-10 Segher Boessenkool
gcc/testsuite/
* gcc.target/powerpc/pr98959.c: Add int128 and lp64 selectors.
---
gcc/testsuite/gcc.target/powerpc/pr98959.c | 2 ++
1 file c
Hiya
> That's because none of the names are overloaded within a single base
> class.
Ah, thanks. Thought there must be something I wasn't thinking of.
> Also, you can use == instead of cp_tree_equal for comparing FUNCTION_DECLs.
Changed it.
Latest patch is attached. Compiles fine and no regres
Here is one more patch for PR99422. The patch was successfully tested
and bootstrapped on x86-64.
commit e647130d441887657cf0e1c2c3b40ab1ca9beb47 (HEAD -> master)
Author: Vladimir N. Makarov
Date: Wed Mar 10 16:15:08 2021 -0500
[PR99422] LRA: Don't check unknown constraint, use X for e
Dear Tobias, all,
> The reason that it is not permitted is the "automatic data object"
> (see *...* highlighted parts in the quote):
>
> C876 (R839) A *variable* whose *designator* appears as a
> *data-stmt-object* or a data-i-do-object hall not be a
> dummy argument, accessed by use or host ass
Dear Harald, dear all,
On 10.03.21 22:26, Harald Anlauf wrote:
[...] I found another testcase which lead to trouble during error
recovery due to a NULL pointer dereference.
I was a bit surprised that the crash only occurs in trans*.c;
however, the error 'non-constant initialization expression'
On Wed, 10 Mar 2021, Alexandre Oliva wrote:
> operand exception for quiet NaN. I couldn't find any evidence that
> the rs6000 backend ever outputs fcmpo. Therefore, I'm adding the same
> execution xfail marker to this test.
In my view, such an XFAIL (for a GCC bug as opposed to an environmental
AIX word-aligns floating point doubles. This behavior also extends to
double _Complex, which had been overlooked when compiler support for
double _Complex was added.
This patch adds DCmode to the modes whose alignment is adjusted and
adds a testcase to confirm the correct alig
Ping^2 for stage 4 P1 issue and attached the patch, Thanks!
On 2021/3/3 09:12, Xionghu Luo via Gcc-patches wrote:
On 2021/2/25 14:33, Xionghu Luo via Gcc-patches wrote:
On 2021/2/25 00:57, Segher Boessenkool wrote:
Hi!
On Wed, Feb 24, 2021 at 09:06:24AM +0800, Xionghu Luo wrote:
vec_ins
On 2/25/21 9:40 PM, Peter Bergner wrote:
> On 2/25/21 7:09 PM, Segher Boessenkool wrote:
>> On Thu, Feb 25, 2021 at 07:05:26PM -0600, Peter Bergner wrote:
>>> The compat builtin patch was approved for backporting to GCC10, so we'll
>>> need this fix to go along with it.
>>
>> Okay for that as well
On 2/11/21 2:22 PM, Peter Bergner wrote:
> The mma_assemble_input_operand predicate is too lenient on the memory
> operands it will accept, leading to an ICE when illegitimate addresses
> are passed in. The solution is to only accept memory operands with
> addresses that are valid for quad word me
On 2/23/21 5:18 PM, Peter Bergner wrote:
> On 2/23/21 4:53 PM, Segher Boessenkool wrote:
>> The patch is okay for trunk and for 10. Thank you!
>
> Fixed and pushed to trunk. I'll push the backport after a day or two
> of burn in on trunk. Thanks!
Pushed to gcc10, so fixed everywhere.
Peter
Forgot to mention: no differences in cris-elf test-results at r11-7500.
Beware, tm.texi doesn't tell the whole story: a defined
HARD_FRAME_POINTER_REGNUM (different to FRAME_POINTER_REGNUM) is
supposed to make work easier for reload, being able to easily
tell actual frame-pointer-related addresses
This patch is to fix PR 99172.
Currently when GCC is configured with --enable-vtable-verify, the
libstdc++-v3 Makefiles add "-fvtable-verify=std
-Wl,-u_vtable_map_vars_start,-u_vtable_map_vars_end" to libtool link
commands. The "-fvtable-verify=std" piece causes alternate versions of
libtool (such
When vect.exp finds our configuration disables altivec by default, it
disables the execution of vectorization tests, assuming the test
hardware doesn't support it.
Tests become just compile tests, but compile tests won't work
correctly when additional sources are named, e.g. pr95401.cc, because
Several ipa-sra tests fail because -mlongcall on powerpc is a
TYPE_ATTRIBUTE, and those disable ipa-sra.
This local workaround disables -mlongcall for the failing tests on
powerpc*-*-vxworks*, so they get a chance to run even in kernel mode.
(AdaCore has -mlongcall enabled for powerpc*-wrs-vxwo
67 matches
Mail list logo
