On Thu, 12 Nov 2020, Joel Hutton wrote:
> Hi all,
>
> This patch adds widening add and widening subtract patterns to
> tree-vect-patterns.
I am missing documentation in md.texi for the new patterns. In
particular I wonder why you need singed and unsigned variants
for the add/subtract
On Thu, 12 Nov 2020, Jan Hubicka wrote:
> Hi,
> this is updated patch. It fixes the comparsion of bitfield where I now
> check that they bitsizes and bitoffsets match (and OEP_ADDRESSOF is not
> used for bitfield references).
> I also noticed problem with dependence clique in ao_refs_may_alias
On Thu, 12 Nov 2020, Jan Hubicka wrote:
> > On Thu, 12 Nov 2020, Jan Hubicka wrote:
> >
> > > Hi,
> > > this is updated patch I am re-testing and plan to commit if it suceeds.
> > >
> > > * fold-const.c (operand_compare::operand_equal_p): Compare
> > > offsets of fields in component_refs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64711
--- Comment #8 from rguenther at suse dot de ---
On Thu, 12 Nov 2020, ebotcazou at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64711
>
> --- Comment #7 from Eric Botcazou ---
> > The issue with clearing nothrow is
Oh I was dry-run but cc to gcc patches accidentally, but the patch set
is right, it just sent twice the same patch set.
On Fri, Nov 13, 2020 at 3:29 PM Kito Cheng wrote:
>
> - New option -misa-spec support: -misa-spec=[2.2|20190608|20191213] and
>corresponding configuration option
- CSR related instructions and fence instructions has to be splitted from
baseline ISA, zicsr and zifencei are corresponding sub-extension.
gcc/ChangeLog:
* common/config/riscv/riscv-common.c (riscv_implied_info):
d and f implied zicsr.
(riscv_ext_flag_table): Handle
- ISA spec has specify the order between multi-letter extensions, implied
extension also need to follow store in canonical ordering, so
most easy way is we keep that in-order during insertion.
gcc/ChangeLog:
* common/config/riscv/riscv-common.c (single_letter_subset_rank): New.
- New option -misa-spec support: -misa-spec=[2.2|20190608|20191213] and
corresponding configuration option --with-isa-spec.
- Current default ISA spec set to 2.2, but we intend to bump this to
20191213 or later in next release.
gcc/ChangeLog:
* common/config/riscv/riscv-common.c
Current GCC implementation is RISC-V ISA 2.2, this patch set implement
v20190608 and v20191213, and also add option -misa-spec=[2.2|20190608|20191213]
to change the default ISA spec version.
There is one major incompatible
That option will effect the default version of each sub-extension, for
- New option -misa-spec support: -misa-spec=[2.2|20190608|20191213] and
corresponding configuration option --with-isa-spec.
- Current default ISA spec set to 2.2, but we intend to bump this to
20191213 or later in next release.
gcc/ChangeLog:
* common/config/riscv/riscv-common.c
- ISA spec has specify the order between multi-letter extensions, implied
extension also need to follow store in canonical ordering, so
most easy way is we keep that in-order during insertion.
gcc/ChangeLog:
* common/config/riscv/riscv-common.c (single_letter_subset_rank): New.
Current GCC implementation is RISC-V ISA 2.2, this patch set implement
v20190608 and v20191213, and also add option -misa-spec=[2.2|20190608|20191213]
to change the default ISA spec version.
There is one major incompatible
That option will effect the default version of each sub-extension, for
- CSR related instructions and fence instructions has to be splitted from
baseline ISA, zicsr and zifencei are corresponding sub-extension.
gcc/ChangeLog:
* common/config/riscv/riscv-common.c (riscv_implied_info):
d and f implied zicsr.
(riscv_ext_flag_table): Handle
On Thu, 12 Nov 2020, Martin Jambor wrote:
> Hi,
>
> On Wed, Nov 11 2020, Richard Biener wrote:
> > On Mon, 9 Nov 2020, Martin Jambor wrote:
> >
> >> this patch modifies the loop invariant pass so that is can operate
> >> only on a single requested loop and its sub-loops and ignore the rest
> >>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64101
Richard Biener changed:
What|Removed |Added
Resolution|--- |INVALID
Status|NEW
- When expanding the call pattern, choose t1 register be a jump register.
Epilogue also uses a t1 register to adjust Stack point. The call pattern
and epilogue will initial t1 twice, if both are generated in the same
function. The call pattern will emit 'la t1,symbol' and 'jalr
On 11/6/20 12:09 PM, Jeff Law wrote:
So I think the best path forward is to let you and Eduard-Mihai make the
technical decisions about what bits are ready for the trunk. When y'all
think something is ready, let's go ahead and get it installed and
iterate on things that aren't quite ready yet.
Hi
Thanks for reminding me about this patch. I didn't remove any existing
intrinsics, just remove redundant builtin functions that end-users
would not likely to use.
Also I'm OK to keep current implementation, in case there might be
someone using the builtin directly.
Jeff Law 于2020年11月13日周五
On 12/23/19 10:31 PM, Hongyu Wang wrote:
> Hi:
> For avx512f scalar instructions, current builtin function like
> __builtin_ia32_*{sd,ss}_round can be replaced by
> __builtin_ia32_*{sd,ss}_mask_round with mask parameter set to -1. This
> patch did the replacement and remove the corresponding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87142
--- Comment #4 from martin ---
With yesterdays master branch, I still see an invalid read with valgrind and an
"AddressSanitizer: heap-use-after-free"-error with -fsanitize=address. So looks
like this has not been fixed by the patch for PR
On Linux/x86_64,
93fc47746815ea9dac413322fcade2931f757e7f is the first bad commit
commit 93fc47746815ea9dac413322fcade2931f757e7f
Author: Jonathan Wakely
Date: Thu Nov 12 21:25:14 2020 +
libstdc++: Optimise std::future::wait_for and fix futex polling
caused
FAIL:
On 11/23/19 11:26 PM, Bin.Cheng wrote:
> On Fri, Nov 22, 2019 at 3:23 PM Bin.Cheng wrote:
>> On Fri, Nov 22, 2019 at 3:19 PM Richard Biener
>> wrote:
>>> On November 22, 2019 6:51:38 AM GMT+01:00, Li Jia He
>>> wrote:
On 2019/11/21 8:10 PM, Richard Biener wrote:
> On Thu, Nov
On 11/29/19 12:15 PM, Tim Rühsen wrote:
> * cplus-dem.c (ada_demangle): Correctly calculate the demangled
> size by using two passes.
So I'm not sure why, but I can't get this patch to apply. What's even
more interesting is ada_demangle doesn't seem to have changed since 2010
and even if I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46769
H.J. Lu changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On 9/2/20 6:59 PM, Austin Morton via Gcc-patches wrote:
> #pragma region is a feature introduced by Microsoft in order to allow
> manual grouping and folding of code within Visual Studio. It is
> entirely ignored by the compiler. Clang has supported this feature
> since 2012 when in MSVC
On 11/12/20 7:02 PM, Xionghu Luo via Gcc wrote:
> Hi all,
>
> In PR51505(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51505), Paolo Bonzini
> added the code to delete REG_EQUAL notes in df_remove_dead_eq_notes:
>
> gcc/df-problems.c:
> df_remove_dead_eq_notes (rtx_insn *insn, bitmap live)
> {
>
2020-11-13 Haochen Gui
* MAINTAINERS (Write After Approval): add myself
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index a0216185de9..be42e1441ca 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -409,6 +409,7 @@ Matthew Gretton-Dann
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96121
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19808
Marek Polacek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92492
--- Comment #7 from Hongtao.liu ---
I notice TARGET_VECTORIZE_RELATED_MODE is added, and can be used to handle
convertion, i'm working on this.
I've invited you to fill out the following form:
Re: Order
To fill it out, visit:
https://docs.google.com/forms/d/e/1FAIpQLSdvTz-uNrwzYEDRle3NKO8L0HG7h5hasmZNnR2EPGRKB8tXPQ/viewform?vc=0c=0w=1flr=0usp=mail_form_link
Ive invited you to fill out a form:
Google Forms: Create and analyze surveys.
在 2020/11/13 2:46, Joseph Myers 写道:
> I'd expect these patches to include updates to the gcc.dg/format/ms_*.c
> tests to reflect the changed semantics (or new tests there if some of the
> changes don't result in any failures in the existing tests).
>
Does the attached patch suffice?
I know
Ping^2, thanks.
On 2020/11/5 09:34, Xionghu Luo via Gcc-patches wrote:
Ping.
On 2020/10/10 16:08, Xionghu Luo wrote:
Originated from
https://gcc.gnu.org/pipermail/gcc-patches/2020-September/554240.html
with patch split and some refinement per review comments.
Patch of IFN VEC_SET for
Hi all,
In PR51505(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51505), Paolo Bonzini
added the code to delete REG_EQUAL notes in df_remove_dead_eq_notes:
gcc/df-problems.c:
df_remove_dead_eq_notes (rtx_insn *insn, bitmap live)
{
...
case REG_EQUAL:
case REG_EQUIV:
{
On Fri, Nov 13, 2020 at 3:32 AM Gerald Pfeifer wrote:
>
> Per our discussion on the list (plus a grammer improvement in a
> section above).
>
> One question: why are the ISA extension lists not alphabetically
> sorted? Wouldn't that be beneficial for users? Easier to find
> something and also
Got it.
On Fri, Nov 13, 2020 at 3:26 AM Gerald Pfeifer wrote:
>
> On Wed, 11 Nov 2020, Hongtao Liu via Gcc-patches wrote:
> > + New ISA extension support for Intel AVX-VNNI was added to GCC.
>
> More for the future (i.e., no need to change that now): I suggest
> to skip "to GCC" in cases like
On Fri, Nov 13, 2020 at 5:50 AM Jim Wilson wrote:
>I committed and pushed it.
Thanks for your help!!
> I see some extra ifunc related testsuite failures, but that is because we
> don't have the glibc ifunc patches upstream yet. It will be important to get
> those done next.
Yeah, hope we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97534
--- Comment #5 from Richard Earnshaw ---
No, I don't think it's related to that, in fact, I think this is just a latent
bug that's been in the code for a long time.
At one point we have a 32-bit signed integer containing INT_MIN, which is
On 11/12/20 4:12 PM, Andrew MacLeod via Gcc-patches wrote:
On 11/12/20 3:53 PM, Richard Biener wrote: ...
But it means that gimple_expr_code() isn't returning the correct result
for GIMPLE_SINGLE_RHS
It depends. A SSA name isn't an expression code either. As said, the
generic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96322
--- Comment #2 from Jonathan Wakely ---
We really need to create our own custom locales for testing, so that we don't
depend on externally defined data that keep changing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #35 from Jim Wilson ---
By combine issue, are you referring to the regression I mentioned in comment 3
and filed as bug 97747? We can handle that as a separate issue. It should be
uncommon. I expect to get much more benefit from
To poll a std::future to see if it's ready you have to call one of the
timed waiting functions. The most obvious way is wait_for(0s) but this
was previously very inefficient because it would turn the relative
timeout to an absolute one by calling system_clock::now(). When the
relative timeout is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95048
--- Comment #9 from Christian Fersch ---
But is it possible to query the value of -fwide-exec-charset? I had quick look
and couldn't find anything.
On Thu, 12 Nov 2020, Iain Sandoe wrote:
> OK for the C-family changes?
OK.
> +When @var{nullability kind} is @var{"unspecified"} or @var{0}, nothing is
I think you mean @code or @samp for the second and third @var on this
line, they look like literal code not metasyntactic variables.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96322
--- Comment #1 from Sergei Trofimovich ---
Maybe pick another similar locale? Candidates are:
glibc $ git grep '0;0' localedata/locales/ | cat
localedata/locales/aa_DJ:grouping 0;0
localedata/locales/bs_BA:grouping
On Thu, Nov 12, 2020 at 04:44:09PM -0500, Michael Meissner wrote:
> On Thu, Nov 12, 2020 at 01:26:32PM -0600, Segher Boessenkool wrote:
> > On Thu, Oct 22, 2020 at 06:12:31PM -0400, Michael Meissner wrote:
> > > Two of the tests used the __ieee128 keyword instead of __float128. This
> > > patch
On 29/05/20 07:17 +0100, Mike Crowe via Libstdc++ wrote:
The futex system call supports waiting for an absolute time if
FUTEX_WAIT_BITSET is used rather than FUTEX_WAIT. Doing so provides two
benefits:
1. The call to gettimeofday is not required in order to calculate a
relative timeout.
2.
On 10/11/2020 6:01 pm, Jakub Jelinek wrote:
One thing is that max-active-levels-var in 5.0 is per-device,
but in 5.1 per-data environment. The question is if we should implement
the problematic 5.0 way or the 5.1 one. E.g.:
#include
#include
int
main ()
{
#pragma omp parallel
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87291
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
In assemly code, the section flag 'R' sets the SHF_GNU_RETAIN flag to
indicate that the section must be preserved by the linker.
Add SECTION_RETAIN to indicate a section should be retained by the linker
and set SECTION_RETAIN on section for the preserved symbol if assembler
supports
This patch adds various entrypoints to libgccjit for directly embedding
asm statements into a compile, analogous to inline asm in the C frontend:
gcc_jit_block_add_extended_asm
gcc_jit_block_end_with_extended_asm_goto
gcc_jit_extended_asm_as_object
gcc_jit_extended_asm_set_volatile_flag
Snapshot gcc-8-20201112 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/8-20201112/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 8 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
This patch fixes a bug in recording::string::make_debug_string in which
'\t' and '\n' were "escaped" by simply prepending a '\', thus emitting
'\' then '\n', rather than '\' then 'n'. It also removes a hack that
determined if a string is to be escaped by checking for a leading '"',
by instead
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to master as 8948a5715b00fe36d20c03b6c4c4397b74cc6282.
gcc/jit/ChangeLog:
* libgccjit.h: Fix typo in comment.
---
gcc/jit/libgccjit.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On 11/12/20 1:27 PM, Patrick Palka wrote:
The atom_cache in normalize_atom relies on the assumption that two
equivalent (templated) trees (in the sense of cp_tree_equal) must use
the same template parameters (according to find_template_parameters).
This assumption unfortunately doesn't always
On Mon, Nov 9, 2020 at 11:15 PM Monk Chiang wrote:
> diff --git a/gcc/config/riscv/riscv.h b/gcc/config/riscv/riscv.h
> index 172c7ca7c98..3bd1993c4c9 100644
> --- a/gcc/config/riscv/riscv.h
> +++ b/gcc/config/riscv/riscv.h
> @@ -342,9 +342,13 @@ extern const char *riscv_default_mtune (int argc,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9
--- Comment #3 from qinzhao at gcc dot gnu.org ---
This does not look like a bug in the new -fzero-call-used-regs implemenation.
it's more likely an existing bug in data flow analysis.
I made the following change in gcc/function.c to make the
On Tue, Nov 10, 2020 at 7:33 PM Nelson Chu wrote:
> gcc/
> * configure: Regenerated.
> * configure.ac: If ifunc was supported in the binutils for
> linux toolchain, then set enable_gnu_indirect_function to yes.
>
Looks good. I committed and pushed it.
I see
On Thu, Nov 12, 2020 at 01:26:32PM -0600, Segher Boessenkool wrote:
> Hi,
>
> On Thu, Oct 22, 2020 at 06:12:31PM -0400, Michael Meissner wrote:
> > Two of the tests used the __ieee128 keyword instead of __float128. This
> > patch changes those cases to use the official keyword.
>
> What is
On Thu, Oct 29, 2020 at 10:05:38PM +, Joseph Myers wrote:
> On Thu, 29 Oct 2020, Segher Boessenkool wrote:
>
> > > Doing these conversions accurately is nontrivial. Converting via strings
> > > is the simple approach (i.e. the one that moves the complexity somewhere
> > > else). There are
Hi,
The PR notes that our inability to parse these keywords in GNU Objective-C
is one of the contributing factors to being unable to use some important
system
headers (at least, on Darwin platforms).
tested on x86_64-darwin and x86_64-linux-gnu,
OK for the C-family changes?
thanks
Iain
—
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85796
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
C2x adds the __has_c_attribute preprocessor operator, similar to C++
__has_cpp_attribute.
GCC implements __has_cpp_attribute as exactly equivalent to
__has_attribute. (The documentation says they differ regarding the
values returned for standard attributes, but that's actually only a
matter of
On 11/12/20 3:53 PM, Richard Biener wrote:
On November 12, 2020 9:43:52 PM GMT+01:00, Andrew MacLeod via Gcc-patches
wrote:
So I spent some time tracking down a ranger issue, and in the end, it
boiled down to the range-op handler not being picked up properly.
The handler is picked up by:
On November 12, 2020 9:43:52 PM GMT+01:00, Andrew MacLeod via Gcc-patches
wrote:
>So I spent some time tracking down a ranger issue, and in the end, it
>boiled down to the range-op handler not being picked up properly.
>
>The handler is picked up by:
>
> if ((gimple_code (s) == GIMPLE_ASSIGN)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
CC||qinzhao at gcc dot gnu.org
So I spent some time tracking down a ranger issue, and in the end, it
boiled down to the range-op handler not being picked up properly.
The handler is picked up by:
if ((gimple_code (s) == GIMPLE_ASSIGN) || (gimple_code (s) ==
GIMPLE_COND))
return range_op_handler (gimple_expr_code
Hi!
For now, task/taskloop constructs aren't handled and C/C++ array reductions
and reductions with task or inscan modifiers need further work.
Instead of calling omp_alloc/omp_free (where the former doesn't have
alignment argument and omp_aligned_alloc is 5.1 only feature), this calls
Hi,
On Wed, Nov 11 2020, Richard Biener wrote:
> On Mon, 9 Nov 2020, Martin Jambor wrote:
>
>> this patch modifies the loop invariant pass so that is can operate
>> only on a single requested loop and its sub-loops and ignore the rest
>> of the function, much like it currently ignores basic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82314
--- Comment #7 from anlauf at gcc dot gnu.org ---
The ICE in comment#0 vanishes when one replaces
integer,parameter::iarray(merge(2,3,.true.)) = 1
with
integer,parameter::iarray(merge(2,3,.true.)) = [ 1, 1 ]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97534
James Clarke changed:
What|Removed |Added
CC||jrtc27 at jrtc27 dot com,
The following patch implements asm goto with outputs. Kernel
developers several times expressed wish to have this feature. Asm
goto with outputs was implemented in LLVM recently. This new feature
was presented on 2020 linux plumbers conference
On Thu, 12 Nov 2020, Iain Sandoe wrote:
> OK for the c-family parts?
OK.
--
Joseph S. Myers
jos...@codesourcery.com
Hi all,
This patch adds backend patterns for vec_widen_add, vec_widen_sub on aarch64.
All 3 patches together bootstrapped and regression tested on aarch64.
Ok for stage 1?
gcc/ChangeLog:
2020-11-12 Joel Hutton
* config/aarch64/aarch64-simd.md: New patterns
vec_widen_saddl_lo/hi_
Hi all,
This patch adds support in the aarch64 backend for the vec_widen_shift
vect-pattern and makes a minor mid-end fix to support it.
All 3 patches together bootstrapped and regression tested on aarch64.
Ok for stage 1?
gcc/ChangeLog:
2020-11-12 Joel Hutton
*
Hi all,
This patch adds widening add and widening subtract patterns to
tree-vect-patterns.
All 3 patches together bootstrapped and regression tested on aarch64.
gcc/ChangeLog:
2020-11-12 Joel Hutton
* expr.c (expand_expr_real_2): add widen_add,widen_subtract cases
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97798
--- Comment #17 from Jonathan Wakely ---
Nice, with binutils HEAD my gcc-10 build continues. Thanks!
On Fri, 6 Nov 2020, Liu, Hongtao wrote:
> I realize you're talking about the patch for gcc-wwwdocs.
> No, I didn't send out a patch, sorry for that, will do it in further commit.
Thanks - saw that. Jeff just beat me to it. :-)
Gerald
Per our discussion on the list (plus a grammer improvement in a
section above).
One question: why are the ISA extension lists not alphabetically
sorted? Wouldn't that be beneficial for users? Easier to find
something and also easier to compare?
Gerald
---
htdocs/gcc-11/changes.html | 13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97798
--- Comment #16 from jozefl at gcc dot gnu.org ---
(In reply to Jonathan Wakely from comment #15)
> Hmm, I get the same error for a out-of-tree binutils built from today's git
> sources:
>
> GNU assembler (GNU Binutils) 2.35.50.20201112
>
Hi,
On Thu, Oct 22, 2020 at 06:12:31PM -0400, Michael Meissner wrote:
> Two of the tests used the __ieee128 keyword instead of __float128. This
> patch changes those cases to use the official keyword.
What is "official" about that?
Why make this change at all? __ieee128 should work as well!
On Wed, 11 Nov 2020, Hongtao Liu via Gcc-patches wrote:
> + New ISA extension support for Intel AVX-VNNI was added to GCC.
More for the future (i.e., no need to change that now): I suggest
to skip "to GCC" in cases like this, since this is our context to
begin with.
Gerald
Hi!
On 2020-11-12T12:45:24+0100, Tobias Burnus wrote:
> For code like
> !$acc kernels
> ... a lot of loops and other code
> !$acc end kernels
>
> gfortran generates
>#pragma ..._kernels
> {
>... lot of code
> }
>
> As the PR shows, the location associated with the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97782
--- Comment #6 from CVS Commits ---
The master branch has been updated by Thomas Schwinge :
https://gcc.gnu.org/g:9106c51e57c06e88a0dddf994fb5432b4bbe68c0
commit r11-4951-g9106c51e57c06e88a0dddf994fb5432b4bbe68c0
Author: Thomas Schwinge
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63287
--- Comment #4 from Jonathan Wakely ---
Library patch:
diff --git a/libgcc/gthr.h b/libgcc/gthr.h
index f31cf083cbe5..e6462679b362 100644
--- a/libgcc/gthr.h
+++ b/libgcc/gthr.h
@@ -147,6 +147,13 @@ see the files COPYING3 and COPYING.RUNTIME
On 11/12/20 10:15 AM, Bill Schmidt via Gcc wrote:
On 11/12/20 10:06 AM, Marc Glisse wrote:
Does the i386 mm_malloc.h file match your scenario?
Ah, that looks promising indeed, and perhaps very simple! Marc,
thanks for the pointer!
And indeed, with this example it was a two-line change
Final bits for libstdc/71579
std::common_type assertions attempt to give a proper 'required from
here' hint for user code, do not bring many changes to the
implementation and check all the template parameters for completeness.
In some cases the type could be checked for completeness more than
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97787
--- Comment #5 from Adrian Bunk ---
(In reply to Richard Biener from comment #4)
> You can also try to 'reduce' the testcase. Since you are linking a shared
> object you can try to strip as many linker inputs as possible and then
> reduce the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97814
--- Comment #3 from Jonathan Wakely ---
N.B. that's not a copy constructor, it's a move constructor.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97814
--- Comment #2 from Jonathan Wakely ---
There is no copy in C++17, it is elided, so lock(S(1)) is equivalent to lock(1)
in C++17, and that constructor exists.
GCC is correct.
I'd expect these patches to include updates to the gcc.dg/format/ms_*.c
tests to reflect the changed semantics (or new tests there if some of the
changes don't result in any failures in the existing tests).
--
Joseph S. Myers
jos...@codesourcery.com
On Thu, Nov 12, 2020 at 01:27:23PM -0500, Patrick Palka wrote:
> The atom_cache in normalize_atom relies on the assumption that two
> equivalent (templated) trees (in the sense of cp_tree_equal) must use
> the same template parameters (according to find_template_parameters).
>
> This assumption
Hi,
could the SLS Mitigation patches be back-ported to the gcc-8 branch?
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=dc586a74922 aarch64:
Introduce SLS mitigation for RET and BR instructions
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=20da13e395b aarch64:
New Straight Line
On Thu, Nov 12, 2020 at 7:26 PM Uros Bizjak wrote:
>
> On Thu, Nov 12, 2020 at 6:51 PM Uros Bizjak wrote:
>
> > > > > Yes, removed 'code' and value_mode by checking VECTOR_MODE_P and use
> > > > > GET_MODE_INNER
> > > > > for value_mode. ".md expanders" shall support for integer constants
> >
On Thu, Nov 12, 2020 at 09:15:11AM -0700, Jeff Law wrote:
> > void foo (void)
> > {
> > register float __attribute__ ((mode(SD))) r31 __asm__ ("r31");
> > register float __attribute__ ((mode(SD))) fr1 __asm__ ("fr1");
> >
> > __asm__ ("#" : "=d" (fr1));
> > r31 = fr1;
> > __asm__ ("#" :
The atom_cache in normalize_atom relies on the assumption that two
equivalent (templated) trees (in the sense of cp_tree_equal) must use
the same template parameters (according to find_template_parameters).
This assumption unfortunately doesn't always hold for TARGET_EXPRs,
because cp_tree_equal
On Thu, Nov 12, 2020 at 6:51 PM Uros Bizjak wrote:
> > > > Yes, removed 'code' and value_mode by checking VECTOR_MODE_P and use
> > > > GET_MODE_INNER
> > > > for value_mode. ".md expanders" shall support for integer constants
> > > > index mode, but
> > > > I guess they shouldn't be expanded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63287
--- Comment #3 from Jonathan Wakely ---
I tried to implement this by adding a macro definition to c_cpp_builtins in
gcc/c-family/c-cppbuiltin.c but failed. I think we want to inspect the
'thread_model' global variable and see if it is "single",
Hi,
On Fri, Aug 7, 2020 at 6:18 AM Richard Sandiford wrote:
>
> https://gcc.gnu.org/g:5380912a17ea09a8996720fb62b1a70c16c8f9f2
>
> commit r9-8794-g5380912a17ea09a8996720fb62b1a70c16c8f9f2
> Author: Richard Sandiford
> Date: Fri Aug 7 12:17:37 2020 +0100
could you please also apply this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9
Uroš Bizjak changed:
What|Removed |Added
CC||qing.zhao at oracle dot com
Last
1 - 100 of 243 matches
Mail list logo
