Hi Chung-Lin!
On 2022-09-21T15:45:54+0800, Chung-Lin Tang via Gcc-patches
wrote:
> [...] The attached patch adds bar.red instructions to the nvptx port [...]
I see GCC report:
[...]
build/genrecog [...]/source-gcc/gcc/common.md
[...]/source-gcc/gcc/config/nvptx/nvptx.md \
On Wed, Jan 11, 2023 at 05:07:47PM -0500, Paul Koning wrote:
> > On Jan 11, 2023, at 2:28 PM, Segher Boessenkool
> > wrote:
> > I would say your predicates are way too lenient here (general_operand),
> > but this needs more info. A testcase to reproduce the problem, to
> > start with :-)
>
> I'
Rather obvious fix for that ICE.
Comments? If there are none, I will commit it later as obvious.
Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
Heurung, Frank Thürauf
On Thu, Jan 12, 2023 at 11:22:40AM +0100, Tobias Burnus wrote:
> Rather obvious fix for that ICE.
>
> Comments? If there are none, I will commit it later as obvious.
I think the spec should be clarified, unlike clauses like if, novariants,
nocontext, indirect, final clause operands where we speci
On Wed, Jan 11, 2023 at 11:59:27AM +, Wilco Dijkstra wrote:
> Hi,
>
> > On 1/10/23 19:12, Jakub Jelinek via Gcc-patches wrote:
> >> Anyway, the sooner this makes it into gcc trunk, the better, it breaks
> >> quite
> >> a lot of stuff.
> >
> > Yep, please, we're also waiting for this patch for
On Thu, 12 Jan 2023 at 01:27, Thomas Rodgers wrote:
>
> I agree with this change.
Thanks, pushed to trunk.
>
> On Thu, Jan 5, 2023 at 4:22 PM Jonathan Wakely wrote:
>>
>> How about this?
>>
>> I don't think we should worry about targets without atomic int, so don't
>> bother using types smaller
On Thu, 12 Jan 2023 at 05:52, François Dumont wrote:
>
> Small update for an obvious compilation issue and to review new test
> case that could have lead to an infinite loop if the increment issue was
> not detected.
>
> I also forgot to ask if there is more chance for the instantiation to be
> eli
OK for trunk, sorry for not getting to it sooner.
On Wed, 4 Jan 2023 at 21:13, François Dumont via Libstdc++
wrote:
>
> Still no chance to review ?
>
> On 14/11/22 18:56, François Dumont wrote:
> > Gentle reminder.
> >
> > Sorry if I should have committed it as trivial but I cannot do it
> > anym
On Thu, 12 Jan 2023 at 12:01, Jonathan Wakely wrote:
>
> OK for trunk, sorry for not getting to it sooner.
P.S. I do think this one would have been OK to commit as obvious,
since it's just removing an unused variable and so has no effect on
anything.
>
> On Wed, 4 Jan 2023 at 21:13, François Dum
On Mon, 28 Nov 2022 at 20:44, François Dumont wrote:
>
> On 28/11/22 19:35, Jonathan Wakely wrote:
>
>
>
> On Mon, 28 Nov 2022 at 06:07, François Dumont via Libstdc++
> wrote:
>>
>> This patch is fixing those tests:
>>
>> 20_util/to_chars/float128_c++23.cc
>> std/format/formatter/requirements.cc
Jakub Jelinek writes:
> On Wed, Jan 11, 2023 at 11:59:27AM +, Wilco Dijkstra wrote:
>> Hi,
>>
>> > On 1/10/23 19:12, Jakub Jelinek via Gcc-patches wrote:
>> >> Anyway, the sooner this makes it into gcc trunk, the better, it breaks
>> >> quite
>> >> a lot of stuff.
>> >
>> > Yep, please, we'r
Richard Sandiford via Gcc-patches writes:
> Jakub Jelinek writes:
>> On Wed, Jan 11, 2023 at 11:59:27AM +, Wilco Dijkstra wrote:
>>> Hi,
>>>
>>> > On 1/10/23 19:12, Jakub Jelinek via Gcc-patches wrote:
>>> >> Anyway, the sooner this makes it into gcc trunk, the better, it breaks
>>> >> quit
First, I messed up the PR number – it should be PR107706.
On 12.01.23 11:39, Jakub Jelinek wrote:
On Thu, Jan 12, 2023 at 11:22:40AM +0100, Tobias Burnus wrote:
Rather obvious fix for that ICE.
Comments? If there are none, I will commit it later as obvious.
I think the spec should be clarifie
On Thu, Jan 12, 2023 at 12:05:45PM +, Richard Sandiford wrote:
> Jakub Jelinek writes:
> > On Wed, Jan 11, 2023 at 11:59:27AM +, Wilco Dijkstra wrote:
> >> Hi,
> >>
> >> > On 1/10/23 19:12, Jakub Jelinek via Gcc-patches wrote:
> >> >> Anyway, the sooner this makes it into gcc trunk, the b
On Wed, Jan 11, 2023 at 8:26 PM Takayuki 'January June' Suwa
wrote:
>
> This branch instruction has short encoding if EQ/NE comparison against
> immediate zero when the Code Density Option is enabled, but its "length"
> attribute was only for normal encoding. This patch fixes it.
>
> This patch a
On Wed, Jan 11, 2023 at 8:26 PM Takayuki 'January June' Suwa
wrote:
>
> This patch saves one byte when the Code Density Option is enabled,
>
> gcc/ChangeLog:
>
> * config/xtensa/xtensa.md (ctzsi2, ffssi2):
> Rearrange the emitting codes.
> ---
> gcc/config/xtensa/xtensa.md | 8 +++
With -ffast-math we end up associating reduction chains and break
them - this is because of old code that tries to rectify reductions
into a shape likened by the vectorizer. Nowadays the rank compute
produces correct association for reduction chains and the vectorizer
has robust support to fall ba
Christophe Lyon writes:
> While looking at PR 105549, which is about fixing the ABI break
> introduced in GCC 9.1 in parameter alignment with bit-fields, we
> noticed that the GCC 9.1 warning is not emitted in all the cases where
> it should be. This patch fixes that and the next patch in the ser
On Tue, Jan 3, 2023 at 2:17 PM Roger Sayle wrote:
>
>
> This patch is an update/tweak of Andrew Pinski's two patches for
> PR tree-optimization/92342, that were originally posted back in November:
> https://gcc.gnu.org/pipermail/gcc-patches/2021-November/585111.html
> https://gcc.gnu.org/pipermail
On Tue, Dec 27, 2022 at 5:12 AM Alexandre Oliva via Gcc-patches
wrote:
>
>
> try_store_by_multiple_pieces was added not long ago, enabling
> variable-sized memset to be expanded inline when the worst-case
> in-range constant length would, using conditional blocks with powers
> of two to cover all
Christophe Lyon writes:
> While working on enabling DFP for AArch64, I noticed new failures in
> gcc.dg/compat/struct-layout-1.exp (t028) which were not actually
> caused by DFP types handling. These tests are generated during 'make
> check' and enabling DFP made generation different (not sure if
On Thu, Dec 22, 2022 at 6:42 PM Andrew Carlotti wrote:
>
> On Thu, Nov 24, 2022 at 11:41:31AM +0100, Richard Biener wrote:
> > Note we do have CTZ and CLZ
> > optabs and internal functions - in case there's a HImode CLZ this
> > could be elided. More general you can avoid using the __builtin_
> >
On Thu, Dec 22, 2022 at 6:44 PM Andrew Carlotti via Gcc-patches
wrote:
>
> Bootstrapped and regression tested on aarch64-unknown-linux-gnu and
> x86_64-pc-linux-gnu - ok to merge?
OK.
Thanks,
Richard.
> gcc/ChangeLog:
>
> * tree-ssa-loop-niter.cc (build_popcount_expr): Add IFN support.
On 1/12/23 14:19, Richard Sandiford wrote:
Christophe Lyon writes:
While working on enabling DFP for AArch64, I noticed new failures in
gcc.dg/compat/struct-layout-1.exp (t028) which were not actually
caused by DFP types handling. These tests are generated during 'make
check' and enabling DF
On 1/12/23 14:03, Richard Sandiford wrote:
Christophe Lyon writes:
While looking at PR 105549, which is about fixing the ABI break
introduced in GCC 9.1 in parameter alignment with bit-fields, we
noticed that the GCC 9.1 warning is not emitted in all the cases where
it should be. This patch
> On Fri, 23 Dec 2022, Jose E. Marchesi via Gcc-patches wrote:
>> This patch adds an entry to the News section in index.html, announcing
>> the availability of a nightly build of bpf-unknown-none-gcc.
>
> Nice!
>
>> +https://godbolt.org";>GCC BPF in Compiler
>> Explorer
>> + [2022-12-23]
>>
> On Fri, 23 Dec 2022, Jose E. Marchesi via Gcc-patches wrote:
>> htdocs/index.html | 24
>> htdocs/news.html | 24
>> 2 files changed, 24 insertions(+), 24 deletions(-)
>
> Okay, thank you.
>
> And you can consider this kind of change preapprov
Hi Chung-Lin, Tom!
It's been a while:
On 2018-09-25T21:11:58+0800, Chung-Lin Tang wrote:
> [...] NVPTX/CUDA-specific implementation
> of the new-style goacc_asyncqueues.
In an OpenACC 'async' setting, where the device kernel (expectedly)
crashes because of "an illegal memory access was encounte
> On Jan 12, 2023, at 4:50 AM, Segher Boessenkool
> wrote:
>
> On Wed, Jan 11, 2023 at 05:07:47PM -0500, Paul Koning wrote:
>>> On Jan 11, 2023, at 2:28 PM, Segher Boessenkool
>>> wrote:
>>> I would say your predicates are way too lenient here (general_operand),
>>> but this needs more info
On Thu, Jan 12, 2023 at 01:28:59PM +0100, Jakub Jelinek wrote:
> > Although we don't AFAIK support using DW_CFA_undefined with RA signing,
> > the failure mode would be non-obvious: it would effectively toggle the
> > bit on.
>
> We don't install unwind-dw2.h nor give user code access to the how a
On Thu, Jan 12, 2023 at 09:17:31AM -0500, Paul Koning wrote:
> > On Jan 12, 2023, at 4:50 AM, Segher Boessenkool
> > wrote:
> > I mean general_operand accepts that sp thing you saw. But your
> > constraints do not? (I don't know your target well, maybe this isn't
> > true). Things like this sh
On 02/12/2022 09:26, Alexandre Oliva via Gcc-patches wrote:
CD-DCE introduces blocks to share common PHI nodes, which replaces a
backwards branch that used to prevent the thumb2 jump table shortening
that PR42093 tested for. In order to keep on testing that the
backward branch prevents the j
On 19/09/2022 17:16, Torbjörn SVENSSON via Gcc-patches wrote:
In the test case, it's clearly written that intrinsics is not
implemented on arm*. A simple xfail does not help since there are
link error and that would cause an UNRESOLVED testcase rather than
XFAIL.
By chaning to dg-skip-if, the
> On Jan 12, 2023, at 9:40 AM, Segher Boessenkool
> wrote:
>
> On Thu, Jan 12, 2023 at 09:17:31AM -0500, Paul Koning wrote:
>>> On Jan 12, 2023, at 4:50 AM, Segher Boessenkool
>>> wrote:
>>> I mean general_operand accepts that sp thing you saw. But your
>>> constraints do not? (I don't kn
Jakub Jelinek writes:
> On Thu, Jan 12, 2023 at 01:28:59PM +0100, Jakub Jelinek wrote:
>> > Although we don't AFAIK support using DW_CFA_undefined with RA signing,
>> > the failure mode would be non-obvious: it would effectively toggle the
>> > bit on.
>>
>> We don't install unwind-dw2.h nor give
Prathamesh Kulkarni writes:
> On Fri, 5 Aug 2022 at 17:49, Richard Sandiford
> wrote:
>>
>> Prathamesh Kulkarni writes:
>> > Hi Richard,
>> > Following from off-list discussion, in the attached patch, I wrote pattern
>> > similar to vec_duplicate_reg, which seems to work for the svld1rq
>> > te
On Thu, Jan 12, 2023 at 03:22:56PM +, Richard Sandiford wrote:
> If we have a new enum, I think we should handle it explicitly. The fact
> that the information isn't propagated between frames is a key part of
> the semantics.
>
> >> Another option is to just define the arch dependent value fo
Jakub Jelinek writes:
> On Thu, Jan 12, 2023 at 03:22:56PM +, Richard Sandiford wrote:
>> If we have a new enum, I think we should handle it explicitly. The fact
>> that the information isn't propagated between frames is a key part of
>> the semantics.
>>
>> >> Another option is to just defi
Prathamesh Kulkarni writes:
> On Tue, 6 Dec 2022 at 07:01, Prathamesh Kulkarni
> wrote:
>>
>> On Mon, 5 Dec 2022 at 16:50, Richard Sandiford
>> wrote:
>> >
>> > Richard Sandiford via Gcc-patches writes:
>> > > Prathamesh Kulkarni writes:
>> > >> Hi,
>> > >> For the following test-case:
>> > >>
From 0821df518b264e754d698d399f98be1a62945e32 Mon Sep 17 00:00:00 2001
From: Longjun Luo
Date: Thu, 12 Jan 2023 23:59:54 +0800
Subject: [PATCH] libcpp: suppress builtin macro redefined warnings for
__LINE__
As implied in
gcc.gnu.org/legacy-ml/gcc-patches/2008-09/msg00076.html,
gcc provides -Wno
On 12/2/2022 5:10 AM, Joseph Myers wrote:
On Fri, 2 Dec 2022, Longjun Luo via Gcc-patches wrote:
They are ./gcc/testsuite/gcc.dg/cpp/warn-redefined.c and
./gcc/testsuite/gcc.dg/cpp/warn-redefined-2.c
These two cases redefine the __TIME__ macro when using the option
'-Wbuiltin-macro-redefined'.
Thanks for doing this and sorry for the slow review.
Lulu Cheng writes:
> Hi, Richard:
>
> Could you please help me look at this document? Is there any problem
> with my modification?
>
> Thanks!
>
>
> 在 2022/12/27 下午2:42, Lulu Cheng 写道:
>> Co-authored-by: Yang Yujie
>>
>> gcc/ChangeLog:
>>
>
Ping David:
Some more notes about the try/catch API:
I finally got unwinding implemented in rustc_codegen_gcc with the
following GCC patch:
https://github.com/antoyo/gcc/commit/fd603a3c715d3708f831cb637fbcc48bf4641859
It still requires clean-up, but you can have a look at it.
I'm still unsure for
Jakub Jelinek via Gcc-patches writes:
> On Tue, Jan 03, 2023 at 02:25:21PM +0100, Florian Weimer wrote:
>> > Though, I still wonder, because all of this is a hack for a single target
>> > - x86_64-linux -m64 - I think no other target has similar constant
>> > sizes,
>>
>> Really? That's odd.
>
>
Ping
On 04/01/23 1:58 pm, Surya Kumari Jangala via Gcc-patches wrote:
> swap: Fix incorrect lane extraction by vec_extract() [PR106770]
>
> In the routine rs6000_analyze_swaps(), special handling of swappable
> instructions is done even if the webs that contain the swappable
> instructions are no
On Thu, Jan 12, 2023 at 04:50:07PM +, Richard Sandiford wrote:
> I'm jumping in here without fully understanding the context, so maybe this
> is exactly your point, but: the SIMD/FP DWARF registers are supposed to be
> size 8 regardless of which features are enabled. That's already only half
>
On 12/01/23 13:00, Jonathan Wakely wrote:
On Thu, 12 Jan 2023 at 05:52, François Dumont wrote:
Small update for an obvious compilation issue and to review new test
case that could have lead to an infinite loop if the increment issue was
not detected.
I also forgot to ask if there is more chance
On Tue, Jan 10, 2023 at 04:33:59PM +, Wilco Dijkstra via Gcc-patches wrote:
> Hi Szabolcs,
>
> > i would keep the assert: how[reg] must be either UNSAVED or UNDEFINED
> > here, other how[reg] means the toggle cfi instruction is mixed with
> > incompatible instructions for the pseudo reg.
> >
>
On 1/11/23 12:58, Jakub Jelinek wrote:
Hi!
The following testcase is miscompiled, because we shorten the division
in a case where it should not be shortened.
Divisions (and modulos) can be shortened if it is unsigned division/modulo,
or if it is signed division/modulo where we can prove the divi
On Thu, Jan 12, 2023 at 02:37:13PM -0500, Jason Merrill wrote:
> > But the C++ FE was checking if op0 is a NOP_EXPR from TYPE_UNSIGNED.
> > First of all, not sure if the operand of NOP_EXPR couldn't be non-integral
> > type where TYPE_UNSIGNED wouldn't be meaningful, but more importantly,
> > even
On Thu, Jan 12, 2023 at 08:55:32PM +0100, Jakub Jelinek via Gcc-patches wrote:
> > > So, the following patch for the NOP_EXPR cases checks just in case that
> > > it is from integral type and more importantly checks it is a widening
> > > conversion, and then next to it also allows op0 to be just u
Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* doc/xml/manual/abi.xml: Add latest library versions.
* doc/html/manual/abi.html: Regenerate.
---
libstdc++-v3/doc/html/manual/abi.html | 4 ++--
libstdc++-v3/doc/xml/manual/abi.xml | 4 +++-
2 files changed, 5 insertions(+),
Tested x86_64-linux. Pushed to trunk.
-- >8 --
GCC's std::max_align_t doesn't agree with the system malloc on HP-UX, so
generalize the current hack for Solaris to apply to that target too.
libstdc++-v3/ChangeLog:
PR libstdc++/77691
* include/experimental/memory_resource
Jakub Jelinek writes:
> On Thu, Jan 12, 2023 at 04:50:07PM +, Richard Sandiford wrote:
>> I'm jumping in here without fully understanding the context, so maybe this
>> is exactly your point, but: the SIMD/FP DWARF registers are supposed to be
>> size 8 regardless of which features are enabled.
I was asked about this privately. I don't really like that it would ever
be needed, but it also seems fairly harmless. We already do similar
things for some of the libstdc++ versions of etc.
Any objections?
Tested x86_64-linux.
-- >8 --
This shouldn't be needed, but apparently the Bazel build
Tested x86_64-linux. Bootstrapped x86_64-w64-mingw32 with both
--enable-threads=posix and --enable-threads=win32.
I need a libgcc or mingw maintainer to approve the gthr-win32.h part.
OK for trunk?
-- >8 --
GCC 13 has a new implementation of gthr-win32.h which supports C++11
mutexes, threads et
Existing hash_table traits that use the same representation for empty
and deleted slots reject marking slots as deleted, and to not pass
is_deleted for slots that pass is_empty.
Nevertheless, nearly everywhere, we only test for is_deleted after
checking that !is_empty first. The one exception w
On Thu, 12 Jan 2023 at 18:25, François Dumont wrote:
>
> On 12/01/23 13:00, Jonathan Wakely wrote:
> > On Thu, 12 Jan 2023 at 05:52, François Dumont wrote:
> >> Small update for an obvious compilation issue and to review new test
> >> case that could have lead to an infinite loop if the increment
We should not directly check flag_strict_flex_arrays in the middle end.
Instead, check DECL_NOT_FLEXARRAY(array_field_decl) which is set by
C/C++ FEs according to -fstrict-flex-arrays and the corresponding attribute
attached to the array_field.
As a result, We will lose the LEVEL information of -f
this is the patch to replace all references to flag_strict_flex_arrays
with DECL_NOT_FLEXARRAY in middle-end per the discussion.
I have bootstrapped and regression tested on X86, no issues.
Okay for commit?
thanks.
Qing
https://gcc.gnu.org/pipermail/gcc-patches/2022-December/607647.html
May I please ping this one again? It will enable closing out the PR. Thanks!
-Lewis
On Thu, Dec 1, 2022 at 9:22 AM Lewis Hyatt wrote:
>
> Hello-
>
> https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599397.html
>
> May I ple
Tested x86_64-linux and powerpc64le-linux. Pushed to trunk.
-- >8 --
The , , and headers use
std::errc constants, but don't use std::system_error itself. They only
use the __throw_system_error(int) function, which is defined in
.
By including the header for the errc constants instead of the who
Tested x86_64-linux and powerpc64le-linux. Pushed to trunk.
-- >8 --
The new symbols need to be exported, as well as some of the
std::locale::facet::id globals, which are not new but were presumably
not needed by any inline functions before now.
libstdc++-v3/ChangeLog:
PR libstdc++/1083
Tested on x86-64-darwin21.
OK for trunk?
Iain
--- 8< ---
Somehow this setting had been missed, and we really need the verbose
flag to enable useful debug output.
Signed-off-by: Iain Sandoe
gcc/m2/ChangeLog:
* gm2-gcc/m2options.h (M2Options_SetVerbose): Export the
function.
On Thu, Jan 12, 2023 at 09:31:23PM +0100, Jakub Jelinek via Gcc-patches wrote:
> On Thu, Jan 12, 2023 at 08:55:32PM +0100, Jakub Jelinek via Gcc-patches wrote:
> > > > So, the following patch for the NOP_EXPR cases checks just in case that
> > > > it is from integral type and more importantly check
Hi!
As mentioned in the PR, various x86 intrinsics need to return
an uninitialized vector. Currently they use self initialization
to avoid -Wuninitialized warnings, which works fine in C, but
doesn't work in C++ where -Winit-self is enabled in -Wall.
We don't have an attribute to mark a variable
Hi!
In https://gcc.gnu.org/pipermail/gcc-patches/2023-January/609844.html
I've posted a patch to allow ignoring -Winit-self using GCC diagnostic
pragmas, such that one can mark self-initialization as intentional
disabling of -Wuninitialized warnings.
The following incremental patch uses that in t
On 1/12/23 21:10, Jonathan Wakely wrote:
Tested x86_64-linux. Bootstrapped x86_64-w64-mingw32 with both
--enable-threads=posix and --enable-threads=win32.
I need a libgcc or mingw maintainer to approve the gthr-win32.h part.
OK for trunk?
Looks good to me even if its a dummy member. Thanks f
On Tue, 10 Jan 2023 at 12:59, Dimitrij Mijoski via Libstdc++
wrote:
>
> Fixes the conversion from UTF-8 to UTF-16 to properly return partial
> instead ok.
> Fixes the conversion from UTF-16 to UTF-8 to properly return partial
> instead ok.
> Fixes the conversion from UTF-8 to UCS-2 to properly ret
Iain Sandoe writes:
> Tested on x86-64-darwin21.
> OK for trunk?
> Iain
yes LGTM,
thanks,
Gaius
> --- 8< ---
>
> Somehow this setting had been missed, and we really need the verbose
> flag to enable useful debug output.
>
> Signed-off-by: Iain Sandoe
>
> gcc/m2/ChangeLog:
>
> * gm2-gcc/
On 1/12/23 19:32, Jakub Jelinek wrote:
Hi!
As mentioned in the PR, various x86 intrinsics need to return
an uninitialized vector. Currently they use self initialization
to avoid -Wuninitialized warnings, which works fine in C, but
doesn't work in C++ where -Winit-self is enabled in -Wall.
We do
Co-authored-by: Yang Yujie
gcc/ChangeLog:
* config/loongarch/loongarch.cc (loongarch_classify_address):
Add precessint for CONST_INT.
(loongarch_print_operand_reloc): Operand modifier 'c' is supported.
(loongarch_print_operand): Increase the processing of '%c'.
On Fri, Jan 13, 2023 at 1:36 AM Jakub Jelinek wrote:
>
> Hi!
>
> In https://gcc.gnu.org/pipermail/gcc-patches/2023-January/609844.html
> I've posted a patch to allow ignoring -Winit-self using GCC diagnostic
> pragmas, such that one can mark self-initialization as intentional
> disabling of -Wunin
On Thu, 12 Jan 2023, Qing Zhao wrote:
> We should not directly check flag_strict_flex_arrays in the middle end.
> Instead, check DECL_NOT_FLEXARRAY(array_field_decl) which is set by
> C/C++ FEs according to -fstrict-flex-arrays and the corresponding attribute
> attached to the array_field.
>
> As
On Thu, Jan 12, 2023 at 10:32 PM Alexandre Oliva via Gcc-patches
wrote:
>
>
> Existing hash_table traits that use the same representation for empty
> and deleted slots reject marking slots as deleted, and to not pass
> is_deleted for slots that pass is_empty.
>
> Nevertheless, nearly everywhere, w
75 matches
Mail list logo
