On 1/23/20 2:52 PM, Alexander Monakov wrote:
On Thu, 23 Jan 2020, Martin Liška wrote:
So this doesn't help review including two different target changes. Making
ifunc dispatchers of public functions non-public looks like an unrelated
thing
to the bug (sorry if I mis-suggested). So I feel com
On 1/26/20 6:35 PM, Jeff Law wrote:
On Tue, 2020-01-21 at 13:48 +0100, Martin Liška wrote:
From a3faaced989869867671ceadd89b56fabde225ff Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Thu, 16 Jan 2020 10:38:41 +0100
Subject: [PATCH] Make target_clones resolver fn static.
gcc/ChangeLog:
20
Hello.
The patch is about splitting pair of errors into
error and inform which seems logical to me in this
situation:
/xg++ -B. /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/cpp0x/vt-34314.C
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/cpp0x/vt-34314.C:3:24: error:
template parameter ‘
The deduction guide from an iterator and sentinel used the wrong alias
template and so didn't work.
PR libstdc++/93426
* include/std/span (span): Fix deduction guide.
* testsuite/23_containers/span/deduction.cc: New test.
This used to work correctly but regressed with r279
On 1/26/20 10:18 PM, Marek Polacek wrote:
Sure, that's better, thanks.
Thank you for the fix Marek.
Martin
As the PR shows, there is a pathway through the code where the
no_warning value is not set, which corresponds to a missing check
of the ramp return when it was constructed from the 'get return
object’. Fixed by ensuring that the check of the return value is
carried out for both return cases.
boo
On Fri, Jan 24, 2020 at 11:53 PM Joseph Myers wrote:
>
> On Fri, 24 Jan 2020, Prathamesh Kulkarni wrote:
>
> > The middle-end representation issue of ERF_RETURNS_ARG still remains,
> > which restricts the attribute till first four args. The patch simply
> > emits sorry(), for arguments beyond firs
Hi Richard,
On 23/01/2020 15:28, Richard Sandiford wrote:
> Dennis Zhang writes:
>> Hi all,
>> On 16/12/2019 13:53, Dennis Zhang wrote:
>>> Hi all,
>>>
>>> This patch is part of a series adding support for Armv8.6-A features.
>>> It depends on the Armv8.6-A effective target checking patch,
>>> ht
On 24/01/2020 14:59, Tobias Burnus wrote:
As reported in PR93409, the build of libgomp/plugin/plugin-gcn.c fails
with a bunch of error messages when building with
--with-multilib-list=m32,m64,mx32
The reason is that the GCN plugin assumes 64bit pointers. As with HSA,
the build is only enabled
On 1/27/20 6:43 AM, Iain Sandoe wrote:
As the PR shows, there is a pathway through the code where the
no_warning value is not set, which corresponds to a missing check
of the ramp return when it was constructed from the 'get return
object’. Fixed by ensuring that the check of the return value i
Dennis Zhang writes:
> [...]
> gcc/ChangeLog:
>
> 2020-01-23 Dennis Zhang
>
> * config/aarch64/aarch64-builtins.c (TYPES_TERNOP_SSUS): New macro.
> * config/aarch64/aarch64-simd-builtins.def (simd_smmla): New.
> (simd_ummla, simd_usmmla): New.
> * config/aarch64/aarch64-
Hi.
The patch is about missing atomic profiler function for indirect calls.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
gcc/ChangeLog:
2020-01-27 Martin Liska
PR gcov-profile/93403
* tree-profile.c (gimple_in
Yes, I know :(
Thank you for your help. All four patches pushed.
Claudiu
On Wed, Jan 22, 2020 at 10:31 PM Jeff Law wrote:
>
> On Wed, 2020-01-22 at 10:14 +0200, Claudiu Zissulescu wrote:
> > ARC600 when configured with mul64 instructions uses mlo and mhi
> > registers to store the 64 result of t
On Mon, 2020-01-27 at 10:57 +0100, Martin Liška wrote:
> Hello.
>
> The patch is about splitting pair of errors into
> error and inform which seems logical to me in this
> situation:
[...]
> diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
> index 4520c995028..f9bed1ea4fb 100644
> --- a/gcc/cp/pt.c
> +++
Semantically, there is an issue when the function name is used both for
recursively calling and as result variable. Hence, one should only use
one own's function name – in context of function calls – if one has a
separate result variable.
This somehow got messed up with r10-5722-g4d12437 (3 J
> From: Jeff Law
> Date: Fri, 20 Sep 2019 17:38:38 +0200
Hi. I'm not going to question
> The first step in that process is to drop support for cc0.
but could you please elaborate on...
> [cc0 support in gcc core]
> code is broken in various ways,
> particularly WRT exceptions.
...that last
There are
static void
parse_mtune_ctrl_str (bool dump)
{
if (!ix86_tune_ctrl_string)
return;
parse_mtune_ctrl_str is only called from set_ix86_tune_features, which
is only called from ix86_function_specific_restore and
ix86_option_override_internal. parse_mtune_ctrl_str shouldn't use
ix86_
Hi!
On 2019-12-20T17:46:57+0100, "Harwath, Frederik"
wrote:
>> > --- a/libgomp/libgomp-plugin.h
>> > +++ b/libgomp/libgomp-plugin.h
>> > @@ -54,6 +54,13 @@ enum offload_target_type
>> >OFFLOAD_TARGET_TYPE_GCN =3D 8
>> > };
>> >=20=20
>> > +/* Container type for passing device properties. *
I've committed this to fix 91826
My changes to is_nested_namespace broke is_ancestor's use where a
namespace alias might be passed in. This changes is_ancestor to look
through the alias.
nathan
--
Nathan Sidwell
gcc/cp/ChangeLog | 5 +
gcc/cp/name-lookup.c
On Fri, Jan 24, 2020 at 12:46 AM Uecker, Martin
wrote:
>
> Am Donnerstag, den 23.01.2020, 14:18 +0100 schrieb Richard Biener:
> > On Wed, Jan 22, 2020 at 12:40 PM Martin Sebor wrote:
> > >
> > > On 1/22/20 8:32 AM, Richard Biener wrote:
> > > > On Tue, 21 Jan 2020, Alexander Monakov wrote:
> > >
> Hi.
>
> The patch is about missing atomic profiler function for indirect calls.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
> Thanks,
> Martin
>
> gcc/ChangeLog:
>
> 2020-01-27 Martin Liska
>
> PR gcov-profile/93403
>
Pushed.
2020-01-27 Richard Biener
PR testsuite/91171
* gcc.dg/graphite/scop-21.c: un-XFAIL.
---
gcc/testsuite/ChangeLog | 5 +
gcc/testsuite/gcc.dg/graphite/scop-21.c | 3 +--
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/gcc/testsuite/Chan
gcc.target/aarch64/cmpimm_branch_1.c started failing after Bernd's
fix to make combine take the costs of jumps into account
(g:391500af1932e696a007). This is because the rtx costs
of *compare_condjump were higher than the costs
of the instructions it combines.
Tested on aarch64-linux-gnu & pushed
On Thu, 2020-01-23 at 17:16 -0500, David Malcolm wrote:
> On Wed, 2020-01-22 at 20:40 +0100, Jakub Jelinek wrote:
> > On Wed, Jan 22, 2020 at 02:35:13PM -0500, David Malcolm wrote:
> > > PR analyzer/93316 reports various testsuite failures where I
> > > accidentally relied on properties of x86_64-p
Part of the problem in this PR is that we don't provide patterns
to extract a 64-bit vector from one half of a 128-bit vector.
Adding them fixes:
FAIL: gcc.target/aarch64/fmul_intrinsic_1.c scan-assembler-times
fmul\\td[0-9]+, d[0-9]+, d[0-9]+ 1
FAIL: gcc.target/aarch64/fmul_intrinsic_1.c scan-as
For the 2s failures in the PR, we have a V4SF VEC_PERM_EXPR in
which the first two elements are duplicates of one element and
the other two are don't-care:
v4sf_b = VEC_PERM_EXPR ;
The heuristic was to extend this with a blend:
v4sf_b = VEC_PERM_EXPR ;
but it seems better to extend a pa
On Fri, 2020-01-24 at 11:16 +0100, Stefan Schulze Frielinghaus wrote:
> On Thu, Jan 23, 2020 at 05:13:20PM -0500, David Malcolm wrote:
> [...]
> > Fixes build on s390x-ibm-linux-gnu for stage 1, at least, with no
> > testsuite regressions. Full bootstrap and regression test run
> > in progress.
>
On 1/27/20 2:38 PM, David Malcolm wrote:
Please add an
auto_diagnostic_group d;
here, so that -fdiagnostics-format=json can nest the note below the
error.
OK with that change.
Sure, there's one another patch that does the for all error+inform
in the function.
Patch can bootstrap on
On Mon, 2020-01-27 at 16:23 +0100, Martin Liška wrote:
> On 1/27/20 2:38 PM, David Malcolm wrote:
> > Please add an
> >auto_diagnostic_group d;
> > here, so that -fdiagnostics-format=json can nest the note below the
> > error.
> >
> > OK with that change.
>
> Sure, there's one another
On 1/21/20 5:19 AM, Iain Sandoe wrote:
Hi Nathan, Bin,
bin.cheng wrote:
Nathan, is this OK for trunk as-is?
thanks
Iain
ok, with one nit I noticed:
+act_des_fn (tree orig, tree fn_type, tree coro_frame_ptr, const char* name)
that final parameter should be 'const char *name' -- the '*'
On 1/20/20 11:08 PM, JunMa wrote:
Hi
This patch does minor fix on changing context of label_decl from
original function to actor function which avoid assertion in gimplify pass.
Bootstrap and test on X86_64, is it OK?
ok, thanks
gcc/cp
2020-01-21 Jun Ma
* coroutines.cc (transform
Ping! Eric, do you have any objections to reverting?
On 21/01/2020 19:16, Vladimir Makarov wrote:
> I am in favour of reverting the patch now. But may be Eric can provide
> another version of the patch not causing the arm problem. I am ready to
> reconsider this too. So I guess the decision is
This test started failing after the switch to -fno-common because we can
now force the array to be aligned to 16 bytes, which in turn lets us use
SIMD accesses. Locally restoring -fcommon seems the most faithful to
the original PR.
Tested on aarch64-linux-gnu & pushed.
Richard
2020-01-27 Rich
On 1/22/20 6:38 AM, bin.cheng wrote:
Hi,
Though function co_await_expander may need to be further revised, this simple
patch fixes an ICE case in co_await_expander,
Handle CO_AWAIT_EXPR in conversion in co_await_expander.
Function co_await_expander expands CO_AWAIT_EXPR and inse
On 1/16/20 4:05 PM, Stam Markianos-Wright wrote:
>
>
> On 1/10/20 6:48 PM, Stam Markianos-Wright wrote:
>>
>>
>> On 12/18/19 1:25 PM, Stam Markianos-Wright wrote:
>>>
>>>
>>> On 12/13/19 10:22 AM, Stam Markianos-Wright wrote:
Hi all,
This patch adds the ARMv8.6 Extension ACLE intr
On 1/16/20 4:06 PM, Stam Markianos-Wright wrote:
>
>
> On 1/8/20 3:18 PM, Stam Markianos-Wright wrote:
>>
>>
>> On 12/10/19 5:03 PM, Kyrill Tkachov wrote:
>>> Hi Stam,
>>>
>>> On 11/15/19 5:26 PM, Stam Markianos-Wright wrote:
Pinging with more correct maintainers this time :)
Als
On 1/21/20 6:21 AM, JunMa wrote:
Hi
When test gcc with cppcoro, I find case like:
int& awaitable::await_resume()
auto x1 = co_await awaitable;
decltype(auto) x2 = co_await awaitable;
Based on standard, typeof(x1) should be int, typeof(x2) is int&.
However, we get both x1 and x2 as int,
Hi!
On Thu, Jan 16, 2020 at 12:50:14PM +, Wilco Dijkstra wrote:
> The separate shrinkwrapping pass may insert stores in the middle
> of atomics loops which can cause issues on some implementations.
> Avoid this by delaying splitting of atomic patterns until after
> prolog/epilog generation.
N
Hi Segher,
> On Thu, Jan 16, 2020 at 12:50:14PM +, Wilco Dijkstra wrote:
>> The separate shrinkwrapping pass may insert stores in the middle
>> of atomics loops which can cause issues on some implementations.
>> Avoid this by delaying splitting of atomic patterns until after
>> prolog/epilog g
Just saw that gcc-patches@ wasn't included in the list. See:
https://gcc.gnu.org/ml/fortran/2020-01/threads.html#00088 for the thread.
Tobias
Forwarded Message
Subject: Re: [Patch][Fortran] On unformatted read, convert != 0 logical
to 1
Date: Mon, 27 Jan 2020 17:29:10 +01
In the gcc.target/aarch64/lsl_asr_sbfiz.c part of this PR, we have:
Failed to match this instruction:
(set (reg:SI 95)
(ashift:SI (subreg:SI (sign_extract:DI (subreg:DI (reg:SI 97) 0)
(const_int 3 [0x3])
(const_int 0 [0])) 0)
(const_int 19 [0x13])))
If
On Mon, 2020-01-27 at 04:53 +, Feng Xue OS wrote:
> Current IPA does not propagate aggregate constant for by-ref argument
> if it is simple pass-through of caller parameter. Here is an example,
>
>f1 (int *p)
>{
> ... = *p;
> ...
>}
>
>f2 (int *p)
>{
> *p =
gcc.dg/pr56350.c started ICEing for SVE in GCC 10 because we
pattern-matched a division reduction:
a /= 8;
into a signed shift with division semantics:
... = IFN_SDIV_POW2 (..., 3);
whereas the reduction code expected it still to be a gassign.
One fix would be to check for a reduct
On Mon, 2020-01-27 at 16:41 +, Richard Sandiford wrote:
> In the gcc.target/aarch64/lsl_asr_sbfiz.c part of this PR, we have:
>
> Failed to match this instruction:
> (set (reg:SI 95)
> (ashift:SI (subreg:SI (sign_extract:DI (subreg:DI (reg:SI 97) 0)
> (const_int 3 [0x3])
>
On Mon, 2020-01-27 at 17:02 +, Richard Sandiford wrote:
> gcc.dg/pr56350.c started ICEing for SVE in GCC 10 because we
> pattern-matched a division reduction:
>
> a /= 8;
>
> into a signed shift with division semantics:
>
> ... = IFN_SDIV_POW2 (..., 3);
>
> whereas the reduction
Hi,
some function calls trigger the stack-protector-strong although such
calls are later on implemented via calls to internal functions.
Consider the following example:
long double
rintl_wrapper (long double x)
{
return rintl (x);
}
On s390x a return value of type `long dou
On Mon, Jan 27, 2020 at 06:49:23PM +0100, Stefan Schulze Frielinghaus wrote:
> some function calls trigger the stack-protector-strong although such
> calls are later on implemented via calls to internal functions.
> Consider the following example:
>
> long double
> rintl_wrapper (long doub
On Mon, 2020-01-27 at 15:01 +0100, Hans-Peter Nilsson wrote:
> > From: Jeff Law
> > Date: Fri, 20 Sep 2019 17:38:38 +0200
>
> Hi. I'm not going to question
>
> > The first step in that process is to drop support for cc0.
>
> but could you please elaborate on...
>
> > [cc0 support in gcc core]
movaps/movups is one byte shorter than movdaq/movdqu. But it isn't the
case for AVX nor AVX512. We should disable TARGET_SSE_TYPELESS_STORES
for TARGET_AVX.
gcc/
PR target/91461
* config/i386/i386.h (TARGET_SSE_TYPELESS_STORES): Disable for
TARGET_AVX.
* config/i
mips_declare_object_name is missing the support for declaring symbols
as gnu_unique_object that is present in the generic
ASM_DECLARE_OBJECT_NAME in elfos.h. I'm not aware of any
MIPS-specific reason for that support to be absent;
mips_declare_object_name predates the addition of gnu_unique_object
Hi all,
This was committed following offline approval by Kyryl.
One minor optimisation introduced by :
https://gcc.gnu.org/ml/gcc-patches/2020-01/msg01237.html
was to set a preference for both __fp16 types and __bf16 types to be
loaded/stored directly into/from the FP/NEON registers (if they ar
On Mon, Jul 8, 2019 at 8:19 AM H.J. Lu wrote:
>
> On Tue, Jun 18, 2019 at 8:59 AM H.J. Lu wrote:
> >
> > On Fri, May 31, 2019 at 10:38 AM H.J. Lu wrote:
> > >
> > > On Tue, May 21, 2019 at 2:43 PM H.J. Lu wrote:
> > > >
> > > > On Fri, Feb 22, 2019 at 8:25 AM H.J. Lu wrote:
> > > > >
> > > > >
On Mon, Jan 13, 2020 at 01:12:15PM -0500, Eric S. Raymond wrote:
> Jonathan Wakely :
> > Email the patches to gcc-patches@gcc.gnu.org, that's how things get
> > merged.
> >
> > We're not looking to change any workflows now.
>
> Roger that.
>
> Once the dust from the conversion has settled, thoug
On Mon, 2019-12-16 at 11:18 +, Bader, Lucas wrote:
> Hello,
>
> within a compile cluster, only the preprocessed output of GCC is transferred
> to remote nodes for compilation.
> When GCC produces advanced diagnostics (with -fdiagnostics-show-caret), e.g.
> prints out the affected source
> l
Since Martin Sebor's patch for PR 71625 to change braced array initializers
to STRING_CST in some cases, we need to be ready for STRING_CST with types
that are changed by tsubst. fold_convert doesn't know how to deal with
STRING_CST, which is reasonable; we really shouldn't expect it to here. So
Hi,
Did you had a chance to review my previous mail which I sent across?
If you are interested please revert me with your target requirement, so that
I can get back to you with more information on the counts and pricing.
Thank you and looking forward for your response.
Regards,
Oli
On Mon, Jan 27, 2020 at 7:23 PM H.J. Lu wrote:
>
> movaps/movups is one byte shorter than movdaq/movdqu. But it isn't the
> case for AVX nor AVX512. We should disable TARGET_SSE_TYPELESS_STORES
> for TARGET_AVX.
>
> gcc/
>
> PR target/91461
> * config/i386/i386.h (TARGET_SSE_TYPE
This patch to the Go frontend adds cleanups now that MPFR 3.1.0 is
required. For MPFR functions, change from GMP_RND* to MPFR_RND*.
Also change mp_exp_t to mpfr_expt_t. This fixes GCC PR 92463.
Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu (with MPFR
4.0.2). Committed to mainline.
Ia
I created PR93461 for this issue: The following code causes a bogus "symbol is
already defined" error (using git commit
73380abd6b2783215c7950a2ade5e3f4b271e2bc):
module aModuleWithAnAllowedName
interface
module subroutine aShortName()
end subroutine aShortName
end interface
On Thu, 2019-12-12 at 15:44 -0500, Jason Merrill wrote:
> Here are the dumps from ssa-dom-thread-7.c made to compile as C++; cx-current
> is the dumps with current trunk; cx-old is changed to use the old goto-based
> lowering like C.
Sorry this has taken so long to get back to.
For ssa-dom-threa
Hi!
On Tue, Jan 21, 2020 at 02:10:21PM +, Wilco Dijkstra wrote:
> While code hoisting generally improves codesize, it can affect performance
> negatively. Benchmarking shows it doesn't help SPEC and negatively affects
> embedded benchmarks. Since the impact is relatively small with -O2 and mai
On Mon, 2020-01-27 at 18:23 +, Joseph Myers wrote:
> mips_declare_object_name is missing the support for declaring symbols
> as gnu_unique_object that is present in the generic
> ASM_DECLARE_OBJECT_NAME in elfos.h. I'm not aware of any
> MIPS-specific reason for that support to be absent;
> mi
* Jeff Law [2020-01-22 13:52:27 -0700]:
> On Wed, 2020-01-22 at 15:39 +, Andrew Burgess wrote:
> > The motivation behind this change is to make it easier for a user to
> > link against static libraries on a target where dynamic libraries are
> > the default library type (for example GNU/Linux
On Mon, Jan 27, 2020 at 12:26 PM Uros Bizjak wrote:
>
> On Mon, Jan 27, 2020 at 7:23 PM H.J. Lu wrote:
> >
> > movaps/movups is one byte shorter than movdaq/movdqu. But it isn't the
> > case for AVX nor AVX512. We should disable TARGET_SSE_TYPELESS_STORES
> > for TARGET_AVX.
> >
> > gcc/
> >
>
I know that the tree's currently closed to non-bugfix changes, but I
was hoping this might be accpeted anyway so it can be backported to
binutils-gdb.
---
Makes some parameters const in libiberty's hashtab library.
include/ChangeLog:
* hashtab.h (htab_remove_elt): Make a parameter const
Hi!
On Wed, Jan 22, 2020 at 07:11:27AM +0100, Hans-Peter Nilsson wrote:
> I intend to put back as many as I find use for, of those
> anonymous patterns in a controlled manner, with self-contained
> test-cases proving their usability, rather than symmetry with
> other instructions and similar addre
Hi!
libgcrypt FAILs to build on aarch64-linux with
*** stack smashing detected ***: terminated
when gcc is compiled with -D_FORTIFY_SOURCE=2. The problem is if
fold_array_ctor_reference is called with size equal to or very close to
MAX_BITSIZE_MODE_ANY_MODE bits and non-zero inner_offset.
The fir
Hi!
The following testcase is miscompiled, because the variable shift left
operand, { -1, -1, -1, -1 } is represented as a VECTOR_CST with
VECTOR_CST_NPATTERNS 1 and VECTOR_CST_NELTS_PER_PATTERN 1, so when
we call builder.new_unary_operation, builder.encoded_nelts () will be just 1
and thus we enc
read model: posix
Supported LTO compression algorithms: zlib
gcc version 10.0.1 20200127 (experimental) (GCC)
$ gfortran -c 1057.F90 -o test.o -ffree-line-length-none
f951: internal compiler error: Segmentation fault
0xe1021f crash_signal
../../gcc-git/gcc/toplev.c:328
0x7f
On Tue, 2020-01-28 at 00:33 +0100, Jakub Jelinek wrote:
> Hi!
>
> libgcrypt FAILs to build on aarch64-linux with
> *** stack smashing detected ***: terminated
> when gcc is compiled with -D_FORTIFY_SOURCE=2. The problem is if
> fold_array_ctor_reference is called with size equal to or very close
On Mon, 2020-01-27 at 22:32 +, Andrew Burgess wrote:
> I know that the tree's currently closed to non-bugfix changes, but I
> was hoping this might be accpeted anyway so it can be backported to
> binutils-gdb.
>
> ---
>
> Makes some parameters const in libiberty's hashtab library.
>
> includ
On Tue, 2020-01-28 at 00:41 +0100, Jakub Jelinek wrote:
> Hi!
>
> The following testcase is miscompiled, because the variable shift left
> operand, { -1, -1, -1, -1 } is represented as a VECTOR_CST with
> VECTOR_CST_NPATTERNS 1 and VECTOR_CST_NELTS_PER_PATTERN 1, so when
> we call builder.new_unar
Hi,
this patch has not changed since the last submission at all, in fact
it got approved but without the follow-up fix of the reverse flag, it
would introduce regression, so it should not be committed on its own.
Because the follow-up patches perform some non-trivial operations on
SRA patches, I
Hi,
this patch fixes the second testcase in PR 92706 by performing total
scalarization only quite a bit later, when we already have access
trees constructed and even done propagation of accesses from RHSs of
assignment to LHSs.
The new code simultaneously traverses the existing access tree and th
Hi,
the previous patch unfortunately does not fix the first testcase in PR
92706 and since I am afraid it might be the important one, I also
focused on that. The issue here is again total scalarization accesses
clashing with those representing accesses in the IL - on another
aggregate but here th
s/jamborm/heads/sra-later_total-bfr-20200127 or look at
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;a=shortlog;h=refs/users/jamborm/heads/sra-later_total-bfr-20200127
if you are interested), but this approach meant that each such
extended replacement which was written to (so all of them) could
pot
On Mon, Jan 27, 2020 at 2:17 PM H.J. Lu wrote:
>
> On Mon, Jan 27, 2020 at 12:26 PM Uros Bizjak wrote:
> >
> > On Mon, Jan 27, 2020 at 7:23 PM H.J. Lu wrote:
> > >
> > > movaps/movups is one byte shorter than movdaq/movdqu. But it isn't the
> > > case for AVX nor AVX512. We should disable TARG
Hi Richard,
thank you for your response.
Am Montag, den 27.01.2020, 15:42 +0100 schrieb Richard Biener:
> On Fri, Jan 24, 2020 at 12:46 AM Uecker, Martin
> wrote:
> >
> > Am Donnerstag, den 23.01.2020, 14:18 +0100 schrieb Richard Biener:
> > > On Wed, Jan 22, 2020 at 12:40 PM Martin Sebor w
PR analyzer/93451 reports an ICE when canonicalizing the constants
in a region_model, with a failed qsort_chk when attempting to sort
the constants within the region_model.
The svalues in the model were:
sv0: {poisoned: uninit}
sv1: {type: ‘double’, ‘0.0’}
sv2: {type: ‘double’, ‘1.0e+0’}
s
On Wed, 2020-01-22 at 20:40 +0100, Jakub Jelinek wrote:
> On Wed, Jan 22, 2020 at 02:35:13PM -0500, David Malcolm wrote:
> > PR analyzer/93316 reports various testsuite failures where I
> > accidentally relied on properties of x86_64-pc-linux-gnu.
> >
> > The following patch fixes them on sparc-su
Hi,
This patch fixes GDC on s390x-linux-musl targets. It was specifically
tested under Alpine Linux (see
https://gitlab.alpinelinux.org/alpine/aports/commit/c123e0f14ab73976a36c651d47d134f249413f29
).
The patch fixes two issues: First, Musl always provide
`__tls_get_addr`, so we can always use it
On Mon, Jan 27, 2020 at 11:17 PM H.J. Lu wrote:
>
> On Mon, Jan 27, 2020 at 12:26 PM Uros Bizjak wrote:
> >
> > On Mon, Jan 27, 2020 at 7:23 PM H.J. Lu wrote:
> > >
> > > movaps/movups is one byte shorter than movdaq/movdqu. But it isn't the
> > > case for AVX nor AVX512. We should disable TAR
On Mon, Jan 27, 2020 at 3:13 PM H.J. Lu wrote:
>
> There are
>
> static void
> parse_mtune_ctrl_str (bool dump)
> {
> if (!ix86_tune_ctrl_string)
> return;
>
> parse_mtune_ctrl_str is only called from set_ix86_tune_features, which
> is only called from ix86_function_specific_restore and
> ix
On Tue, 28 Jan 2020, Uecker, Martin wrote:
> > (*) this also shows the level of "obfuscation" needed to fool compilers
> > to lose provenance knowledge is hard to predict.
>
> Well, this is exactly the problem we want to address by defining
> a clear way to do this. Casting to an integer would be
On Mon, Jan 27, 2020 at 09:09:37PM -0500, David Malcolm wrote:
> > Please see calls.c (special_function_p), you should treat certainly
> > also sigsetjmp as a setjmp call, and similarly to special_function_p,
> > skip over _ or __ prefixes before the setjmp or sigsetjmp name.
> > Similarly for long
85 matches
Mail list logo
