On Thu, Nov 26, 2020 at 12:50:17PM +0800, Hongtao Liu wrote:
> Hi:
> This patch is about to delete dead code in ix86_expand_special_args_builtin.
>
> Bootstrap and regression test are ok.
>
> gcc/ChangeLog:
> * config/i386/i386-expand.c
> (ix86_expand_special_args_builtin): De
On Wed, Nov 25, 2020 at 7:22 PM Martin Sebor wrote:
>
> On 11/25/20 2:31 AM, Richard Biener wrote:
> > 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 someti
Am 25.11.20 um 23:02 schrieb Maciej W. Rozycki:
The Fortran intrinsis like HUGE, EPSILON, SELECTED_REAL_KIND etc
would have to be handled correctly, both for simplification in
the front end and in the library.
Does the program
print *,HUGE(1.0)
print *,EPSILON(1.0)
end
print correct valu
Hi:
This patch is about to delete dead code in ix86_expand_special_args_builtin.
Bootstrap and regression test are ok.
gcc/ChangeLog:
* config/i386/i386-expand.c
(ix86_expand_special_args_builtin): Delete last_arg_constant.
From 948756dae8f67bf766714d9ecc064b4eea9952cd Mon Sep
On Wed, Nov 25, 2020 at 7:37 PM Jakub Jelinek wrote:
>
> 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 re
On Tue, Nov 24, 2020 at 08:34:51PM -0600, Pat Haugen wrote:
> On 11/24/20 8:17 PM, Pat Haugen via Gcc-patches wrote:
> > On 11/24/20 12:59 PM, Carl Love via Gcc-patches wrote:
> >> +(define_insn "modu_"
> >> + [(set (match_operand:VIlong 0 "vsx_register_operand" "=v")
> >> + (umod:VIlong (match_o
Thanks for the review.
BTW, the patch is already installed because uros helped to review this
patch in another thread
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/558682.html
On Thu, Nov 26, 2020 at 3:15 AM Jeff Law wrote:
>
>
>
> On 11/11/20 1:03 AM, Hongtao Liu via Gcc-patches wrote:
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97983
The patch was successfully bootstrapped on x86_64 and s390x (with
--enable-languages=c,c++ --enable-checking=release --disable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable
On 11/25/20 1:50 PM, Jakub Jelinek wrote:
On Wed, Nov 25, 2020 at 12:26:17PM -0500, Jason Merrill wrote:
+ if (DECL_BIT_FIELD (fld)
+ && DECL_NAME (fld) == NULL_TREE)
+ continue;
I think you want to check DECL_PADDING_P here; th
On Linux/x86_64,
bb07490abba850fd5b1d2d09d76d18b8bdc7d817 is the first bad commit
commit bb07490abba850fd5b1d2d09d76d18b8bdc7d817
Author: Jan Hubicka
Date: Wed Nov 25 20:51:26 2020 +0100
Add EAF_NODIRECTESCAPE flag
caused
FAIL: gcc.target/i386/avx512vl-vandnpd-2.c execution test
FAIL: gc
On 11/24/20 9:54 AM, Qing Zhao via Gcc-patches 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
wrote:
Hi,
Does
On 11/13/20 1:14 AM, Richard Sandiford via Gcc-patches wrote:
This patch adds a pointer_mux class that provides similar
functionality to:
union { T1 *a; T2 *b; };
...
bool is_b_rather_than_a;
except that the is_b_rather_than_a tag is stored in the low bit
of the pointer. See the
Jeff Law wrote:
[...]
> By understanding how your proposed changes affect other processors, you
> can write better changes that are more likely to get included.
> Furthermore you can focus efforts on things that matter more in the real
> world. DImode shifts in libgcc are _not_ useful to try an
On 25.11.20 23:02, Maciej W. Rozycki wrote:
Well, it does not link, for the somewhat unsurprising reason of a missing
libgfortran runtime. I have modified the program with whatever little
Fortran skills I gained a while ago to get something that can be parseable
for a human being in the assembl
On Wed, 25 Nov 2020, Uecker, Martin wrote:
> So OK to apply with the following Changelog?
OK fixed as noted.
> 2020-11-25 Martin Uecker
>
> gcc/c/
Should mention the PR number in the ChangeLog entry (the part that will
end up automatically added to the ChangeLog file), not just the
On Tue, Nov 24, 2020 at 05:27:10AM +, Maciej W. Rozycki wrote:
> On Tue, 24 Nov 2020, Maciej W. Rozycki wrote:
>
> > > I don't know how or why __FLT_HAS_INFINITY is set for a target which
> > > does not support it, but if you get rid of that macro, that particular
> > > problem should be solve
On Wed, 25 Nov 2020, Maciej W. Rozycki wrote:
> For the other pieces that are missing perhaps my work I did many years
> ago to port glibc 2.4 (the last one I was able to cook up without NPTL),
> and specifically libm within, to the never-upstreamed VAX/Linux target
> might be useful to comple
On 11/25/20 2:22 PM, Stefan Kanthak wrote:
> Jakub Jelinek wrote:
>
>> On Wed, Nov 25, 2020 at 09:22:53PM +0100, Stefan Kanthak wrote:
As Jakub has already indicated, your change will result in infinite
recursion on avr.Ã, I happened to have a cr16 handy and it looks like
it'd ge
On Tue, 24 Nov 2020, Eric Botcazou wrote:
> > I'm intested in any notes, however vague, on that matter. I was
> > a bit surprised to see that myself...that is, after fixing
> > *some* related regressions, like the one in combine. (Did I
> > actually miss something?)
>
> My recollection for the V
Make the following simplifications:
X <= MAX(X, Y) -> true
X > MAX(X, Y) -> false
X >= MIN(X, Y) -> true
X < MIN(X, Y) -> false
This fixes PR96708.
Tested on x86_64-pc-linux-gnu.
bool f(int a, int b)
{
int tmp = (a < b) ? b : a;
return tmp >= a;
}
Code without th
On Wed, 25 Nov 2020, Thomas Koenig wrote:
> >xbig = 26.543, xhuge = 6.71e+7, xmax = 2.53e+307;
>
> The Fortran intrinsis like HUGE, EPSILON, SELECTED_REAL_KIND etc
> would have to be handled correctly, both for simplification in
> the front end and in the library.
>
> Does the program
>
Hi!
On 2020-11-25T15:44:56+, Richard Biener wrote:
> 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 can't comment on that one specifically, not using this op
Jakub Jelinek wrote:
> On Wed, Nov 25, 2020 at 09:22:53PM +0100, Stefan Kanthak wrote:
>> > As Jakub has already indicated, your change will result in infinite
>> > recursion on avr.Ã, I happened to have a cr16 handy and it looks like
>> > it'd generate infinite recursion there too.
>>
>> JFTR: d
On 11/25/20 1:22 PM, Stefan Kanthak wrote:
> Jeff Law wrote:
>
>> On 11/24/20 8:40 AM, Stefan Kanthak wrote:
>>> Andreas Schwab wrote:
>>>
On Nov 24 2020, Stefan Kanthak wrote:
> 'nuff said
What's your point?
>>> Pinpoint deficiencies and bugs in GCC and libgcc, plus a counte
On Wed, Nov 25, 2020 at 09:22:53PM +0100, Stefan Kanthak wrote:
> > As Jakub has already indicated, your change will result in infinite
> > recursion on avr.Ã I happened to have a cr16 handy and it looks like
> > it'd generate infinite recursion there too.
>
> JFTR: does GCC emit a warning then?
On 11/13/20 1:21 AM, Richard Sandiford via Gcc-patches wrote:
> This patch adds a routine for finding a “simple” SET for a register
> definition. See the comment in the patch for details.
>
> gcc/
> * rtl.h (simple_regno_set): Declare.
> * rtlanal.c (simple_regno_set): New function.
On 11/13/20 1:20 AM, Richard Sandiford via Gcc-patches wrote:
> When using validate_change to make a group of changes, you have
> to remember to cancel them if something goes wrong. This patch
> adds an RAII class to make that easier. See the comments in the
> patch for details and examples.
>
On 11/13/20 1:19 AM, Richard Sandiford via Gcc-patches wrote:
> In some cases, it can be convenient to roll back the changes that
> have been made by validate_change to see how things looked before,
> then reroll the changes. For example, this makes it possible
> to defer calculating the cost o
Jeff Law wrote:
> On 11/24/20 8:40 AM, Stefan Kanthak wrote:
>> Andreas Schwab wrote:
>>
>>> On Nov 24 2020, Stefan Kanthak wrote:
>>>
'nuff said
>>> What's your point?
>> Pinpoint deficiencies and bugs in GCC and libgcc, plus a counter
>> example to your "argument"!
>> I recommend careful r
On 11/13/20 1:18 AM, Richard Sandiford via Gcc-patches wrote:
> verify_changes has a test for whether a particular hard register
> is a user-defined register asm. A later patch needs to test the
> same thing, so this patch splits it out into a helper.
>
> gcc/
> * rtl.h (register_asm_p):
On 11/13/20 1:17 AM, Richard Sandiford via Gcc-patches wrote:
> Later patches want to use print_insn_with_notes (printing to
> a pretty_printer). This patch exports it from print-rtl.c.
>
> The non-notes version is already public.
>
> gcc/
> * print-rtl.h (print_insn_with_notes): Declare.
On 11/13/20 1:14 AM, Richard Sandiford via Gcc-patches wrote:
> This patch adds a pointer_mux class that provides similar
> functionality to:
>
> union { T1 *a; T2 *b; };
> ...
> bool is_b_rather_than_a;
>
> except that the is_b_rather_than_a tag is stored in the low bit
> of the poi
On 11/13/20 1:14 AM, Richard Sandiford via Gcc-patches wrote:
> This patch adds an RAII class for managing the lifetimes of objects
> on an obstack. See the comments in the patch for more details and
> example usage.
>
> gcc/
> * obstack-utils.h: New file.
RAII is goodness. One could arg
On 11/13/20 1:13 AM, Richard Sandiford via Gcc-patches wrote:
> This patch adds some more iterator helper classes. They really fall
> into two groups, but there didn't seem much value in separating them:
>
> - A later patch has a class hierarchy of the form:
>
> Base
> +- Derived1
>
On 11/13/20 1:13 AM, Richard Sandiford via Gcc-patches wrote:
> A later patch will add more iterator-related utilities. Rather than
> putting them all directly in coretypes.h, it seemed better to add a
> new header file, here called "iterator-utils.h". This preliminary
> patch moves the existi
On 11/13/20 1:12 AM, Richard Sandiford via Gcc-patches wrote:
> noop_move_p currently keeps any instruction that has a REG_EQUAL
> note, on the basis that the equality might be useful in future.
> But this creates a perverse incentive not to add potentially-useful
> REG_EQUAL notes, in case they
On 11/13/20 1:12 AM, Richard Sandiford via Gcc-patches wrote:
> A later patch wants to use the set of global registers as a HARD_REG_SET
> rather than a bool/char array. Most other arrays already have a
> HARD_REG_SET counterpart, but this one didn't.
>
> gcc/
> * hard-reg-set.h (global_r
On 11/13/20 1:11 AM, Richard Sandiford via Gcc-patches wrote:
> I noticed during compatibility testing that clang warns that this
> operator won't be implicitly const in C++14 onwards.
>
> gcc/
> * vec.h (vnull::operator vec): Make const.
OK
jeff
On 11/13/20 1:10 AM, Richard Sandiford via Gcc-patches wrote:
> Just after GCC 10 stage 1 closed (oops), I posted a patch to add a new
> combine pass. One of its main aims was to allow instructions to move
> around where necessary in order to make a combination possible.
> It also tried to para
On 11/23/20 2:09 AM, Kewen.Lin via Gcc-patches wrote:
> Hi,
>
> I adjusted some vectorization test cases for vect_partial_vectors_usage_1
> before, but as exposed in the recent testings, some of them need to be
> adjusted again. The reason is that the commit r11-3393 improved the
> epilogue loo
On 11/19/20 8:59 AM, Qing Zhao via Gcc-patches wrote:
> Hi,
>
> PR9 - ICE: in df_refs_verify, at df-scan.c:3991 with -O
> -ffinite-math-only -fzero-call-used-regs=all
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9
>
> Is a bug triggered by the new pass zero-call-used-regs, however,
Hi,
this constructing testcase for the direct escape analysis I noticed that
I forgot to duplicate arg_flags in duplicate hook so we lose track of
that when clonning. I am sure I had it there at some point, but
apparently it got lost while breaking up patches.
Bootstrapped/regtested x86_64-linux,
On 11/3/20 2:15 PM, Nathan Sidwell wrote:
> Here are the new options, along with the C++ lang-spec changes.
>
> Modules is enabled by -fmodules-ts, it is not implicitly enabled by
> -std=c++20. Usually that's the only option you need to add for a
> module-aware build.
>
> to build a header unit
Hi!
On 2020-11-25T11:52:44+0100, Jakub Jelinek wrote:
> 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' cla
On 11/18/20 2:20 PM, Martin Sebor wrote:
> On 11/18/20 1:41 PM, David Malcolm wrote:
>
>> So hopefully that gives us a way forward. I'm about to disappear for a
>> week and a half, so don't let my analyzer patches stand in the way of
>> Martin's. I can finish reworking my stuff on top of Marti
On Tue, 24 Nov 2020, Thomas Koenig wrote:
> > I am going to give up at this point, as porting libgfortran to non-IEEE FP
> > is surely well beyond what I can afford to do right now.
>
> Can you file a PR about this? Eliminating __builtin_inf and friends
> sounds doable.
There's more to that unf
On 11/3/20 2:15 PM, Nathan Sidwell wrote:
> This is the user documentation.
>
>
> 12-core-doc.diff
>
I think this is fine.
jeff
On 11/11/20 1:03 AM, Hongtao Liu via Gcc-patches wrote:
>
>
>
> vec_set_rebaserebase_onr11-4901.patch
>
> From c9d684c37b5f79f68f938f39eeb9e7989b10302d Mon Sep 17 00:00:00 2001
> From: liuhongt
> Date: Mon, 19 Oct 2020 16:04:39 +0800
> Subject: [PATCH] Support variable index vec_set.
>
> gcc/C
Hi Maciej,
Infinity is the least of a problem, because as it turns out we have
numerous FP library functions in libgfortran that require explicit porting
to each FP format supported, like these settings:
xbig = 26.543, xhuge = 6.71e+7, xmax = 2.53e+307;
The Fortran intrinsis l
Hi!
I've pushed "Fix templatized C++ OpenACC 'cache' directive ICEs" to
master branch in commit 0cab70604cfda30bc64351b39493ef884ff7ba10, and
backported to releases/gcc-10 branch in commit
5bfcc9e103c06d85de43766fe05eb59f4f50c3db, to releases/gcc-9 branch in
commit 1cb1c9e62f92ad674976b0da8cc46d73
Am Montag, den 23.11.2020, 20:21 + schrieb Joseph Myers:
> On Mon, 23 Nov 2020, Uecker, Martin wrote:
>
> > Joseph,
> >
> > here is the patch to not drop qualifiers for _Atomic in
> > typeof. I am not sure whether this is appropriate in
> > stage3, but I wanted to leave it here for you to com
On Wed, 25 Nov 2020, Tobias Burnus wrote:
> Does this solve all infinity issues? Or is there still code requiring it
> implicitly? From the previous exchange, it sounded as if there are still
> issues.
Infinity is the least of a problem, because as it turns out we have
numerous FP library funct
On 11/24/20 8:40 AM, Stefan Kanthak wrote:
> Andreas Schwab wrote:
>
>> On Nov 24 2020, Stefan Kanthak wrote:
>>
>>> 'nuff said
>> What's your point?
> Pinpoint deficiencies and bugs in GCC and libgcc, plus a counter
> example to your "argument"!
> I recommend careful reading.
Umm, you should br
On Wed, Nov 25, 2020 at 12:26:17PM -0500, Jason Merrill wrote:
> > + if (DECL_BIT_FIELD (fld)
> > + && DECL_NAME (fld) == NULL_TREE)
> > + continue;
>
> I think you want to check DECL_PADDING_P here; the C and C++ front ends set
> it on unnamed
For the case where a timeout is specified using the system_clock we
perform a conversion to the preferred clock (which is either
steady_clock or system_clock itself), wait using __cond_wait_until_impl,
and then check the time by that clock again to see if it was reached.
This is entirely redundant,
This introduces a new internal utility, std::__condvar, which is a
simplified form of std::condition_variable. It has no dependency on
or std::unique_lock, which allows it to be used in
.
This avoids repeating the #ifdef __GTHREAD_COND_INIT preprocessor
conditions and associated logic for initial
On 25/11/20 10:35 +, Jonathan Wakely wrote:
I've pushed that as ad9cbcee543ecccd79fa49dafcd925532d2ce210 but there
are still other FAILs to be fixed.
I think the other FAILs are due to a race condition in the tests,
fixed by this patch. Tested x86_64-linux, powerpc64le-linux,
sparc-solaris2
On Fri, 20 Nov 2020, Maciej W. Rozycki wrote:
> These changes have been regression-tested throughout development with the
> `vax-netbsdelf' target running NetBSD 9.0, using said VAXstation 4000/60,
> which uses the Mariah implemementation of the VAX architecture. The host
> used was `powerpc6
On Tue, 24 Nov 2020, Maciej W. Rozycki wrote:
> I am going to give up at this point, as porting libgfortran to non-IEEE FP
> is surely well beyond what I can afford to do right now.
I have now posted fixes for the issues handled so far.
For the other pieces that are missing perhaps my work I
On 11/25/20 2:31 AM, Richard Biener wrote:
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.
Patch looks good to me.
Thanks,
Tobias
PS: Are there still remaining issues to be solved? Or does libgfortran
now build?
On 25.11.20 19:14, Maciej W. Rozycki wrote:
While we have `configure' checks for the individual POSIX 2008 extended
locale functions we refer to and use to guard the respec
LGTM.
Does this solve all infinity issues? Or is there still code requiring it
implicitly? From the previous exchange, it sounded as if there are still
issues.
Tobias
On 25.11.20 19:14, Maciej W. Rozycki wrote:
The *_HAS_* floating-point feature macros are defined as 0/1 rather than
#undef/#de
While we have `configure' checks for the individual POSIX 2008 extended
locale functions we refer to and use to guard the respective call sites,
we only verify the presence of `newlocale' for our global feature enable
check. Consequently compilation fails for targets like NetBSD that only
have
The *_HAS_* floating-point feature macros are defined as 0/1 rather than
#undef/#define settings by gcc/c-family/c-cppbuiltin.c. Consequently we
choose to use infinity and NaN features even with non-IEEE-754 targets
such as `vax-netbsdelf' that lack them, causing build warnings and
failures li
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
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
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
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/
> 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
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 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/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
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 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
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
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
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
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
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
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
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
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
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 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-
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, 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
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
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.
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
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, 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, 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, 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 eges was not garba
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 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
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
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
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
> -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]
1 - 100 of 164 matches
Mail list logo
