On Linux/x86_64,
f2a5cdff0457077cc0ef44a7c52c7dcf3fcaeadb is the first bad commit
commit f2a5cdff0457077cc0ef44a7c52c7dcf3fcaeadb
Author: Martin Sebor
Date: Tue Nov 24 13:28:55 2020 -0700
Add a note.
caused
FAIL: gcc.dg/Wstringop-overflow-47.c note (test for warnings, line 29)
FAIL: gcc.
On 11/24/20 5:22 PM, Kyrylo Tkachov wrote:
Ah, I suppose in the sanitiser case as there are local modifications maybe it's
not a straightforward pre-approval, so don't take my word on it 😉
Martin will probably know the rules here.
Thanks,
Kyrill
Hello.
As I was told by Jeff that libsanitizer
On Linux/x86_64,
c4fa3728ab4f78984a549894e0e8c4d6a253e540 is the first bad commit
commit c4fa3728ab4f78984a549894e0e8c4d6a253e540
Author: Ulrich Weigand
Date: Tue Nov 24 10:32:20 2020 +0100
Fix -ffast-math flags handling inconsistencies
caused
FAIL: gcc.dg/ipa/iinline-attr.c scan-ipa-dum
On Linux/x86_64,
3c45da4414884a5424484f5db1ab951d9de6 is the first bad commit
commit 3c45da4414884a5424484f5db1ab951d9de6
Author: Jason Merrill
Date: Tue Nov 10 18:02:04 2020 -0500
dwarf2: Set DW_AT_declaration for undefined fns [PR97060]
caused
FAIL: gcc.dg/debug/dwarf2/pr97060.
On Tue, Nov 24, 2020 at 5:54 PM Qing Zhao wrote:
>
>
>
> On Nov 24, 2020, at 9:55 AM, Richard Biener
> wrote:
>
> On Tue, Nov 24, 2020 at 4:47 PM Qing Zhao wrote:
>
>
>
>
> On Nov 24, 2020, at 1:32 AM, Richard Biener
> wrote:
>
> On Tue, Nov 24, 2020 at 12:05 AM Qing Zhao via Gcc-patches
> w
On Tue, Nov 24, 2020 at 05:31:03PM -0700, Jeff Law wrote:
> FIrst, do we need to document the new builtin?Â
I think for builtins that are only meant for libstdc++ as underlying
implementation
of its documented in the standard APIs we have some cases where we don't
document them and other cases w
On Thu, 12 Nov 2020 at 06:56, Jason Merrill via Gcc-patches
wrote:
>
> If DECL_INITIAL isn't set, we can't emit anything about the body of the
> function, so add the declaration attribute.
>
> Tested x86_64-pc-linux-gnu, applying to trunk.
>
> gcc/ChangeLog:
>
> PR debug/97060
> *
On Wed, Nov 25, 2020 at 10:24:23AM +0100, Christophe Lyon via Gcc-patches wrote:
> On Thu, 12 Nov 2020 at 06:56, Jason Merrill via Gcc-patches
> wrote:
> >
> > If DECL_INITIAL isn't set, we can't emit anything about the body of the
> > function, so add the declaration attribute.
> >
> > Tested x86
On Wed, Nov 25, 2020 at 1:45 AM Martin Sebor via Gcc-patches
wrote:
>
> Offsets in pointer expressions are signed but GCC prefers to
> represent them as sizetype instead, and sometimes (though not
> always) crashes during GIMPLE verification when they're not.
> The sometimes-but-not-always part ma
Hi,
I’ve had this patch in my Darwin trees for (literally) years, it is
relevant to
the GCC ports that use a non-binutils assembler.
At present, even if such an assembler supports LEB128, the GCC config
is setting HAVE_LEB128 = 0.
The ports I know of that can benefit from a change here are:
Hi!
I had reason to look into OpenMP C++ 'map' clause parsing, and a
testsuite enhancement to "Add 'g++.dg/gomp/map-{1,2}.C'" fell out of
that, see attached. OK to push?
Note two XFAILs in 'g++.dg/gomp/map-1.C' compared to the C/C++ variant.
I suppose these are real, and should get resolved at s
Hi!
The following patch adds some improvements for __builtin_mul_overflow
expansion.
One optimization is for the u1 * u2 -> sr case, as documented we normally
do:
u1 * u2 -> sr
res = (S) (u1 * u2)
ovf = res < 0 || main_ovf (true)
where main_ovf (true) stands for jump on unsign
On Wed, Nov 25, 2020 at 11:00:57AM +0100, Thomas Schwinge wrote:
> I had reason to look into OpenMP C++ 'map' clause parsing, and a
> testsuite enhancement to "Add 'g++.dg/gomp/map-{1,2}.C'" fell out of
> that, see attached. OK to push?
>
> Note two XFAILs in 'g++.dg/gomp/map-1.C' compared to the
On 25/11/20 10:23 +0100, Jakub Jelinek wrote:
On Tue, Nov 24, 2020 at 05:31:03PM -0700, Jeff Law wrote:
FIrst, do we need to document the new builtin?Â
I think for builtins that are only meant for libstdc++ as underlying
implementation
of its documented in the standard APIs we have some case
Hi!
The following patch renames VI12_AVX2 iterator to VI12_AVX2_AVX512BW
for consistency with some other iterators, as I need VI12_AVX2 without
AVX512BW for this change.
The real meat is a pre-reload define_insn_and_split which combine
can use to optimize psubusw compared to 0 into pminuw compared
On 25/11/20 01:07 +, Jonathan Wakely wrote:
On 24/11/20 23:45 +, Jonathan Wakely wrote:
On 21/11/20 16:36 -0800, H.J. Lu wrote:
On Sat, Nov 21, 2020 at 9:40 AM Jonathan Wakely via Gcc-patches
wrote:
On 21/11/20 17:04 +, Jonathan Wakely wrote:
On 21/11/20 16:16 +0100, Andreas Sch
Hi Iain,
> I’ve had this patch in my Darwin trees for (literally) years, it is
> relevant to
> the GCC ports that use a non-binutils assembler.
>
> At present, even if such an assembler supports LEB128, the GCC config
> is setting HAVE_LEB128 = 0.
>
> The ports I know of that can benefit from a c
Hi Jakub!
On 2020-11-25T11:10:18+0100, Jakub Jelinek wrote:
> On Wed, Nov 25, 2020 at 11:00:57AM +0100, Thomas Schwinge wrote:
>> I had reason to look into OpenMP C++ 'map' clause parsing, and a
>> testsuite enhancement to "Add 'g++.dg/gomp/map-{1,2}.C'" fell out of
>> that, see attached. OK to
On Wed, Nov 25, 2020 at 11:43:48AM +0100, Thomas Schwinge wrote:
> On 2020-11-25T11:10:18+0100, Jakub Jelinek wrote:
> > On Wed, Nov 25, 2020 at 11:00:57AM +0100, Thomas Schwinge wrote:
> >> I had reason to look into OpenMP C++ 'map' clause parsing, and a
> >> testsuite enhancement to "Add 'g++.dg
On Wed, Nov 25, 2020 at 11:34 AM Jakub Jelinek wrote:
>
> Hi!
>
> The following patch renames VI12_AVX2 iterator to VI12_AVX2_AVX512BW
> for consistency with some other iterators, as I need VI12_AVX2 without
> AVX512BW for this change.
> The real meat is a pre-reload define_insn_and_split which co
Here, the problem was that we were mixing types when calculating
the product of loop-steps, each type was taken from the loop var.
Solution: take the largest type as diff_type and use it everywhere.
And add a missing 'fold_convert' to fix the actual ICE.
Comments? If not, I will commit it later
On Tue, Nov 24, 2020 at 9:00 PM Jakub Jelinek wrote:
>
> On Tue, Nov 24, 2020 at 10:36:49AM +0800, Hongtao Liu via Gcc-patches wrote:
> > > > * gcc.target/i386/pr97642-2.c: New test.
> > > So in the BZ Jakub asked for the all-ones mask case to be specially
> > > handled to emit a normal load
On Wed, Nov 25, 2020 at 11:57:00AM +0100, Uros Bizjak wrote:
> > I haven't done the AVX512{BW,VL} define_insn_and_split, they'll need
> > to match the UNSPEC_PCMP which are used for avx512 comparisons.
> >
> > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> I *think* this
This makes sure to lower VECTOR_BOOLEAN_TYPE_P typed VEC_COND_EXPRs
so we don't try to use vcond to expand those. That's especially
improtant for x86 integer mode boolean vectors but eventually
as well for aarch64 / gcn VnBImode ones.
Bootstrap and regtest running on x86_64-unknown-linux-gnu.
20
On Wed, Nov 25, 2020 at 07:32:44PM +0800, Hongtao Liu wrote:
> Update patch:
> 1. ix86_expand_special_args_builtin is used for expanding mask load
> intrinsics, this function will always convert the constant mask
> operands into reg. So for the situation of all-ones mask, keep this
> constant, an
On 23.11.20 22:18, Harald Anlauf wrote:
The patch below is based on a previous version by Steve.
The present version fixes an additional copy&paste error.
Needless to say that it (still!) regtests cleanly on x86_64-pc-linux-gnu.
OK for master? As it appears safe, OK for backport to at least 1
Richard Biener writes:
> This makes sure to lower VECTOR_BOOLEAN_TYPE_P typed VEC_COND_EXPRs
> so we don't try to use vcond to expand those. That's especially
> improtant for x86 integer mode boolean vectors but eventually
> as well for aarch64 / gcn VnBImode ones.
>
> Bootstrap and regtest runni
On Wed, Nov 25, 2020 at 12:32 PM Jakub Jelinek wrote:
>
> On Wed, Nov 25, 2020 at 11:57:00AM +0100, Uros Bizjak wrote:
> > > I haven't done the AVX512{BW,VL} define_insn_and_split, they'll need
> > > to match the UNSPEC_PCMP which are used for avx512 comparisons.
> > >
> > > Bootstrapped/regtested
Hello Thomas,
On 15.11.20 18:52, Thomas Koenig via Fortran wrote:
this patch makes sure that we pass the correct fn decls for
some of our library functions. cshift and others still remain
to be implemented.
Thanks
+#define ADD_CHAR(c) do { *fp++ = c; *fp++ = ' '; } while(0)
...
+ ADD_CHAR ('
On 25/11/2020 11:36, Richard Biener wrote:
This makes sure to lower VECTOR_BOOLEAN_TYPE_P typed VEC_COND_EXPRs
so we don't try to use vcond to expand those. That's especially
improtant for x86 integer mode boolean vectors but eventually
as well for aarch64 / gcn VnBImode ones.
GCN does not hav
On 25/11/20 10:35 +, Jonathan Wakely wrote:
On 25/11/20 01:07 +, Jonathan Wakely wrote:
On 24/11/20 23:45 +, Jonathan Wakely wrote:
On 21/11/20 16:36 -0800, H.J. Lu wrote:
On Sat, Nov 21, 2020 at 9:40 AM Jonathan Wakely via Gcc-patches
wrote:
On 21/11/20 17:04 +, Jonathan Wa
On Wed, 25 Nov 2020, Richard Sandiford wrote:
> Richard Biener writes:
> > This makes sure to lower VECTOR_BOOLEAN_TYPE_P typed VEC_COND_EXPRs
> > so we don't try to use vcond to expand those. That's especially
> > improtant for x86 integer mode boolean vectors but eventually
> > as well for aar
On Tue, 24 Nov 2020 at 19:43, Ulrich Weigand via Gcc-patches
wrote:
>
> On Fri, Nov 20, 2020 at 09:33:48PM -0700, Jeff Law wrote:
> > > * doc/invoke.texi (-ffast-math): Remove mention of
> > > -fno-signaling-nans.
> > > Clarify conditions when __FAST_MATH__ preprocessor macro is defined.
Jeff Law wrote:
> On 11/10/20 10:21 AM, Stefan Kanthak wrote:
>
>>> So with all that in mind, I installed everything except the bits which
>>> have the LIBGCC2_BAD_CODE ifdefs after testing on the various crosses.
>>> If you could remove the ifdefs on the abs/mult changes and resubmit them
>>> it
Hi all,
A while back I submitted GCC10 commit:
44f77a6dea2f312ee1743f3dde465c1b8453ee13
for PR91816.
Turns out I was an idiot and forgot to include the test in the actual
git commit, even my entire patch had been approved.
Tested that the test still passes on a cross arm-none-eabi and also
When compiling or analyzing with GNATprove a piece of SPARK code with a
circular definition involving an incomplete declaration and an access to
it, the compilation/analysis may raise Program_Error in some cases. Now
fixed.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* sem
Before this commit, GNAT would crash when encountering uses of the
`Profile` pragma that did not have an identifier as argument (e.g.
`pragma Profile("a")`).
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* sem_prag.adb (Analyze_Pragma): Emit error on wrong argument
n
The support for 128-bit integer types was added to System.Random_Numbers
but not to the twin package GNAT.Random_Numbers.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* libgnat/g-rannum.ads (Random): New functions returning 128-bit.
* libgnat/g-rannum.adb (Random):
exp_ch7.adb was missing calls to Set_Debug_Info_Needed on various
entities to allow debugging via -gnatD, now fixed.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* exp_ch7.adb (Build_Finalization_Master, Build_Finalizer,
Build_Object_Declarations, Make_Deep_Array_Bo
This patch remove recursion on Set_Digit and Set_Image_Unsigned
procedure.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* libgnat/s-imagei.adb
(Set_Digits): Rewrite the procedure to remove recursion.
(Image_Integer, Set_Image_Integer): Update assertions and
The previous change to __gnat_copy_attribs led to relying on utimes for
timestamp propagation on VxWorks 6 as well, which results in undefined
symbol references at runtime in most configurations for such targets.
Restore the previous code for such environments, based on utime instead.
Tested on x
While the default function returning 128-bit integer works correctly,
Random_Discrete does not if it is instantiated on a 128-bit integer,
since the magnitude of the returned numbers is still 64 bits.
Note that no counterpart is needed in GNAT.Random_Numbers because the
homonymous function in ther
This patch fixes an error in the compiler whereby right shift operators
on signed integers cause a compile-time crash when said shift operators
are provided via pragma Provide_Shift_Operators.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* doc/gnat_rm/intrinsic_subprograms.
Access type parameters in instances of generic units were first checked
with Subtypes_Match routine, and then their designated types were
checked for matching constrained-ness; diagnostic code guarded by both
conditions was duplicated.
It turns out that the constrained-ness condition was never act
Mistake detected as a code duplicate. It only suppresses a more precise
error on a code that is rejected as illegal anyway.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* sem_ch13.adb (Analyze_One_Aspect): Replace duplicate of
Effective_Reads.diff --git a/gcc/ada/se
By convention subprogram declarations in Einfo unit use alias "E"
instead of Entity_Id, but subprogram bodies use full Entity_Id types.
This patch fixes inconsistencies where alias "E" was used in subprogram
bodies. Cleanup only; semantics is unaffected.
Tested on x86_64-pc-linux-gnu, committed on
SPARK code is much more restricted in terms of possible side-effects
inside expressions. As such, there is no need for aggressive removal of
side-effects across all expressions in GNATprove mode. The benefit is
that expressions are more self-contained, without the need to get
information from hoist
In a case like:
X : Integer := 1;
Y : Integer renames Integer'(X);
the value of Y is changed by any subsequent assignments to X. Thus,
replacing the use of X with a literal 1 would be a mistake.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* exp_ch2.adb (Expand_Enti
Now all calls to Make_Aitem_Pragma, which converts aspects to pragmas,
use hardcoded names as the Pragma_Name parameters, because the required
value is known statically (this actually prevents code reuse, but at
least now all aspects are handled consistenttly). Other calls use Nam
constant instead
Replace sequences of (in)equality tests with membership tests and sort
alternatives alphabetically.
Cleanup related to removal of duplicated code; semantics is unaffected.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* sem_ch13.adb (Analyze_One_Aspect): Detect aspect ident
In Expand_N_Exception_Renaming_Declaration we had a local constant "Nam"
which was then shadowed by a parameter "Nam" in a nested function
Evaluation_Required. Cleanup only; semantics is unaffected.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* exp_ch8.adb (Expand_N_Except
This patch removes an error on an instantiation when the actual is a
scalar type with a dynamic predicate, and its bounds are compatible
with those of the corresponding formal parameter. Section 4.9.1 of
the RM specifies that subtypes S1 and S2 can be statically compatible
even if S1 is not static,
Attribute Has_Tagged_Values was implemented years ago, but never
documented. Found while detecting duplicated code, as this attribute is
processed very much like attribute Has_Access_Type and this duplication
is also removed.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
*
The first one is that the propagation does not work if the raise
statement uses a qualified name for the exception, because of an
inconsistency in Expand_N_Raise_Statement.
The second one is that a pragma Assert (False) does not propagate
locally because the rewriting of the degenerate if statemen
An object declaration for an unconstrained array includes an expression
(most often an aggregate) that provides the bounds for the object. If
the aggregate uses box initialization to provide those bounds, it is not
necessary to construct the aggregate to complete the object declaration:
the generat
Hi,
we discussed this patch briefly two weeks ago, but did not reach conclusion and
since I wanted to avoid ICF fixes slipping another release I had chance to
return to it only now. Main limitation of modref is the fact that it does not
track anything in memory. This is intentional - I wanted the
On Mon, Nov 23, 2020 at 2:02 PM Martin Liška wrote:
>
> On 11/23/20 12:00 PM, Richard Biener wrote:
> > Can you split out the unifying of -[gf]record-gcc-switches processing
> > and the target hook adjustment from the change introducing
> > -frecord-gcc-switches-format?
>
> Sure.
>
> >
> > dwarf2o
Hi all,
Now that I have pushed the entirety of this patch to gcc-10 and gcc-11,
I would like to backport it to gcc-8 and gcc-9.
PR link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91816
This patch had originally been approved here:
https://gcc.gnu.org/legacy-ml/gcc-patches/2020-01/msg02010
This patch enables MVE vandq instructions for auto-vectorization. MVE
vandq insns in mve.md are modified to use 'and' instead of unspec
expression to support and3. The and3 expander is added to
vec-common.md
2020-11-12 Christophe Lyon
gcc/
* gcc/config/arm/iterators.md (supf)
This patch enables MVE vorrq instructions for auto-vectorization. MVE
vorrq insns in mve.md are modified to use ior instead of unspec
expression to support ior3. The ior3 expander is added to
vec-common.md
2020-11-13 Christophe Lyon
gcc/
* config/arm/iterators.md (supf): Remo
This patch enables MVE veorq instructions for auto-vectorization. MVE
veorq insns in mve.md are modified to use xor instead of unspec
expression to support xor3. The xor3 expander is added to
vec-common.md
2020-11-12 Christophe Lyon
gcc/
* config/arm/iterators.md (supf): Remo
This patch enables MVE vshlq instructions for auto-vectorization. A
new MVE pattern is introduced that takes a vector of constants as
second operand, all constants being equal.
The existing mve_vshlq_n_ is kept, as it takes a single
immediate as second operand, and is used by arm_mve.h.
The vash
This patch enables MVE vshr instructions for auto-vectorization. New
MVE patterns are introduced that take a vector of constants as second
operand, all constants being equal.
The existing mve_vshrq_n_ is kept, as it takes a single
immediate as second operand, and is used by arm_mve.h.
The vashr3
This patch enables MVE vmvnq instructions for auto-vectorization. MVE
vmvnq insns in mve.md are modified to use 'not' instead of unspec
expression to support one_cmpl2. The one_cmpl2 expander
is added to vec-common.md.
2020-11-12 Christophe Lyon
gcc/
* config/arm/iterators.md
> -Original Message-
> From: Stam Markianos-Wright
> Sent: 25 November 2020 13:49
> To: gcc-patches@gcc.gnu.org
> Cc: Richard Earnshaw ; Ramana
> Radhakrishnan ; Kyrylo Tkachov
> ; ni...@redhat.com
> Subject: [backport gcc-8,9][arm] Thumb2 out of range conditional branch fix
> [PR91816]
On Wed, 25 Nov 2020, Richard Biener wrote:
> On Wed, 25 Nov 2020, Richard Sandiford wrote:
>
> > Richard Biener writes:
> > > This makes sure to lower VECTOR_BOOLEAN_TYPE_P typed VEC_COND_EXPRs
> > > so we don't try to use vcond to expand those. That's especially
> > > improtant for x86 integer
This libgomp OpenACC testcase makes assumptions about the order in which
loop iterations will run that are invalid on amdgcn. Apparently nvptx
does work that way, but I find that surprising in itself.
For example, this patch ensures that where a test expects one bit left
set, or unset, then it
I'd like to ping for this patch:
https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553870.html
Michael
On 11/10/2020 19.22, Michael Weghorn via Gcc-patches wrote:
On 22/09/2020 12.04, Jonathan Wakely wrote:
On 14/09/20 16:49 +0200, Michael Weghorn via Libstdc++ wrote:
Hi,
the attached
> On Tue, 24 Nov 2020, Jan Hubicka wrote:
>
> > Hi,
> > at the end of processing function body we loop over basic blocks and
> > free all edges while we do not free the rest. I think this is leftover
> > from time eges was not garbage collected and we was not using ggc_free.
> > It makes more sen
Hi,
while looking into structalias I noticed that we ignore EAF flags here.
This is pity since we still can apply direct and unused.
This patch simply copies logic from normal call handling. I relaize that
it is bit more expensive by creating callarg and doing transitive
closure there instead of do
On Wed, Nov 25, 2020 at 3:11 PM Jan Hubicka wrote:
>
> > On Tue, 24 Nov 2020, Jan Hubicka wrote:
> >
> > > Hi,
> > > at the end of processing function body we loop over basic blocks and
> > > free all edges while we do not free the rest. I think this is leftover
> > > from time eges was not garba
On Wed, Nov 25, 2020 at 3:14 PM Jan Hubicka wrote:
>
> Hi,
> while looking into structalias I noticed that we ignore EAF flags here.
> This is pity since we still can apply direct and unused.
> This patch simply copies logic from normal call handling. I relaize that
> it is bit more expensive by c
> On Wed, Nov 25, 2020 at 3:11 PM Jan Hubicka wrote:
> >
> > > On Tue, 24 Nov 2020, Jan Hubicka wrote:
> > >
> > > > Hi,
> > > > at the end of processing function body we loop over basic blocks and
> > > > free all edges while we do not free the rest. I think this is leftover
> > > > from time eg
On Wed, 25 Nov 2020, Jan Hubicka wrote:
> > On Wed, Nov 25, 2020 at 3:11 PM Jan Hubicka wrote:
> > >
> > > > On Tue, 24 Nov 2020, Jan Hubicka wrote:
> > > >
> > > > > Hi,
> > > > > at the end of processing function body we loop over basic blocks and
> > > > > free all edges while we do not free t
On Wed, 25 Nov 2020, Jan Hubicka wrote:
> Hi,
> we discussed this patch briefly two weeks ago, but did not reach conclusion
> and
> since I wanted to avoid ICF fixes slipping another release I had chance to
> return to it only now. Main limitation of modref is the fact that it does not
> track a
On Wed, 25 Nov 2020, Jakub Jelinek wrote:
> Hi!
>
> The following patch adds some improvements for __builtin_mul_overflow
> expansion.
> One optimization is for the u1 * u2 -> sr case, as documented we normally
> do:
> u1 * u2 -> sr
> res = (S) (u1 * u2)
> ovf = res < 0 || ma
The g++spec.c part of this patch
[PATCH] ada: c++: Get rid of libposix4, librt on Solaris
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559341.html
is the only remaining part still needing review by a c++ or driver
maintainer. It's more than a week now.
Thanks.
This fixes the search when configured with --libexecdir=lib64,
I've adjusted the bin reference for consistency.
Testing in progress. Does this look sensible?
2020-11-25 Richard Biener
libgomp/
* configure: Regenerate.
* plugin/configfrag.ac (offload_additional_options): Use
On Wed, Nov 25, 2020 at 04:30:44PM +0100, Richard Biener wrote:
> This fixes the search when configured with --libexecdir=lib64,
> I've adjusted the bin reference for consistency.
>
> Testing in progress. Does this look sensible?
>
> 2020-11-25 Richard Biener
>
> libgomp/
> * configure
Hi!
On Wed, Nov 25, 2020 at 02:02:16PM +0800, Kewen.Lin wrote:
> This patch is to set param_vect_partial_vector_usage as 1 on P10
> by default. Due to the unexpected performance on Power9 of those
> vector with length instructions, we didn't enable vectorization
> with partial vectors before. So
On Wed, 25 Nov 2020, Jakub Jelinek wrote:
> On Wed, Nov 25, 2020 at 04:30:44PM +0100, Richard Biener wrote:
> > This fixes the search when configured with --libexecdir=lib64,
> > I've adjusted the bin reference for consistency.
> >
> > Testing in progress. Does this look sensible?
> >
> > 2020-
On 11/25/20 9:41 AM, Rainer Orth wrote:
The g++spec.c part of this patch
[PATCH] ada: c++: Get rid of libposix4, librt on Solaris
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559341.html
is the only remaining part still needing review by a c++ or driver
maintainer.
This patch to the Go frontend avoids silent integer truncation when
compiling code like string(1 << 32). In the conversion of a constant
integer to a string type, the value of the constant integer was being
silently truncated from unsigned long to unsigned int, producing the
wrong string value. T
For calls like:
z0 = svabs_s8_x (p0, z1)
we previously generated:
abs z0.b, p0/m, z1.b
However, this creates a false dependency on z0 (the merge input).
This can lead to strange results in some cases, e.g. serialising
the operation behind arbitrary earlier operations, or pre
On Wed, Nov 25, 2020 at 10:31:28AM +, Jonathan Wakely via Gcc-patches wrote:
> On 25/11/20 10:23 +0100, Jakub Jelinek wrote:
> > On Tue, Nov 24, 2020 at 05:31:03PM -0700, Jeff Law wrote:
> > > FIrst, do we need to document the new builtin?ÃÂ
> >
> > I think for builtins that are only meant f
On 25/11/20 17:24 +0100, Jakub Jelinek wrote:
On Wed, Nov 25, 2020 at 10:31:28AM +, Jonathan Wakely via Gcc-patches wrote:
On 25/11/20 10:23 +0100, Jakub Jelinek wrote:
> On Tue, Nov 24, 2020 at 05:31:03PM -0700, Jeff Law wrote:
> > FIrst, do we need to document the new builtin?ÃÂ
>
> I th
Hi,
This patch replaces calls to __builtin_neon_vmvnv* builtins with ~
operator in arm_neon.h.
Cross-tested on arm*-*-*.
OK to commit ?
Thanks,
Prathamesh
vmvn-1.diff
Description: Binary data
Hi,
gcc has special behavior for FLT_EVAL_METHOD on s390x that causes
performance impact in some scenarios and fails to align with float_t wrt
the C standard in others. These two patches prepare gcc for a cleanup to
get rid of that special case, to improve standard compliance and avoid
the overhea
Historically, float_t has been defined as double on s390 and gcc would
emit double precision insns for evaluating float expressions when in
standard-compliant mode. Configure that behavior at compile-time as prep
for changes in glibc: When glibc ties float_t to double, keep the old
behavior; when g
Add two test cases that check for acceptable combinations of float_t and
FLT_EVAL_METHOD on s390x.
Tested against an as-is glibc and one modified so that it derives
float_t from FLT_EVAL_METHOD.
gcc/testsuite/ChangeLog:
2020-11-25 Marius Hillenbrand
* gcc.target/s390/float_t-1.c: New
On Mon, 23 Nov 2020, Paul Koning wrote:
> > Then there is a fix for the PDP11 backend addressing an issue I found in
> > the handling of floating-point comparisons. Unlike all the other changes
> > this one has not been regression-tested, not even built as I have no idea
> > how to prepare a d
Hi Christophe,
Thanks for these! See some inline comments.
On 25/11/2020 13:54, Christophe Lyon via Gcc-patches wrote:
This patch enables MVE vandq instructions for auto-vectorization. MVE
vandq insns in mve.md are modified to use 'and' instead of unspec
expression to support and3. The and3 e
On 11/2/20 2:21 PM, Jakub Jelinek wrote:
On Thu, Jul 30, 2020 at 10:16:46AM -0400, Jason Merrill via Gcc-patches wrote:
The following patch adds __builtin_bit_cast builtin, similarly to
clang or MSVC which implement std::bit_cast using such an builtin too.
Great!
Sorry for the long delay.
T
On 11/25/20 9:41 AM, Rainer Orth wrote:
The g++spec.c part of this patch
[PATCH] ada: c++: Get rid of libposix4, librt on Solaris
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559341.html
is the only remaining part still needing review by a c++ or driver
maintainer.
On 11/24/20 8:09 PM, Martin Sebor via Gcc-patches wrote:
The attached patch cleans up most remaining -Wformat-diag instances
in an x86_64-build. I tried to minimize using #pragma diagnostic
so I tweaked the code instead. A preferable solution might be to
introduce a new format attribute and use
> On Nov 25, 2020, at 3:11 AM, Richard Biener
> wrote:
>>
>>
>> Hi,
>>
>> Does gcc provide an iterator to traverse all the local variables that are
>> declared in the current routine?
>>
>> If not, what’s the best way to traverse the local variables?
>>
>>
>> Depends on what for. There
This fixes a failure on AIX 7.2:
FAIL: 17_intro/names.cc (test for excess errors)
Excess errors:
/home/jwakely/src/gcc/libstdc++-v3/testsuite/17_intro/names.cc:99: error:
expected identifier before '(' token
/usr/include/sys/var.h:187: error: expected unqualified-id before '{' token
/usr/include/
libstdc++-v3/ChangeLog:
PR libstdc++/97935
* include/bits/iterator_concepts.h (__detail::__iter_without_category):
New helper concept.
(__iterator_traits::__cat): Use __detail::__iter_without_category.
* testsuite/24_iterators/associated_types/iterator.trait
On 11/25/20 2:49 AM, Iain Sandoe wrote:
> Hi,
>
> I’ve had this patch in my Darwin trees for (literally) years, it is
> relevant to
> the GCC ports that use a non-binutils assembler.
>
> At present, even if such an assembler supports LEB128, the GCC config
> is setting HAVE_LEB128 = 0.
>
> The
On 11/25/20 6:18 AM, Stefan Kanthak wrote:
> Jeff Law wrote:
>
>> On 11/10/20 10:21 AM, Stefan Kanthak wrote:
>>
So with all that in mind, I installed everything except the bits which
have the LIBGCC2_BAD_CODE ifdefs after testing on the various crosses.
If you could remove the i
1 - 100 of 164 matches
Mail list logo
