On Sat, Nov 26, 2022 at 1:19 AM Zopolis0 wrote:
>
> I was reverting a076632e274abe344ca7648b7c7f299273d4cbe0 as it removed code
> for Java, but I may have misunderstood the change and made the incorrect
> edits.
The change is fixing a bug (setting TREE_ADDRESSABLE from a CTOR in
debug stmts) an
On Sat, Nov 26, 2022 at 9:41 AM Zopolis0 wrote:
>
> > What happens if you remove end_params_node from the Java front-end and
> > replace it with void_list_node?
>
> Sadly, nothing.
But that looks like the correct thing to do.
On Mon, Nov 28, 2022 at 6:33 AM HAO CHEN GUI via Gcc-patches
wrote:
>
> Hi,
>Gentle ping this:
> https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607083.html
> Thanks
> Gui Haochen
>
> 在 2022/11/23 10:54, HAO CHEN GUI 写道:
> > Hi,
> > I want to enable "have_cbranchcc4" on rs6000. But n
Hi!
The following testcase fails since my changes to make also
opts_set saved/restored upon function target/optimization changes
(before it has been acting as "has this option be ever explicit
anywhere?").
The problem is that for ix86_abi we depend on the opts_set
value for it in ix86_option_over
On Mon, Nov 28, 2022 at 9:46 AM Jakub Jelinek wrote:
>
> Hi!
>
> The following testcase fails since my changes to make also
> opts_set saved/restored upon function target/optimization changes
> (before it has been acting as "has this option be ever explicit
> anywhere?").
>
> The problem is that f
The following shows a missed update of dominators when unswitching
removes unreachable edges from switch stmts it unswitches. Fixed
by wiping dominator info in that case.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR tree-optimization/107876
* tree-ssa-loop-unsw
Andrea Corallo writes:
> Hi all,
>
> this is the first patch series about improving the current MVE
> implementation and testsuite for:
>
> - Complete intrinsic implementation and coverage (the list of intrinsics is
> specified by [1])
> - Verifying all instructions supposedly emitted by each i
On 28/11/2022 07:40, Tobias Burnus wrote:
It turned out that cprop cleverly propagated the unspec_volatile
to the preceding (pseudo)register, permitting to remove the
'set (s0) (pseudoregister)' at -O2. Unfortunately, it does
matter whether the assignment is done to 's2' (previously: pseudoregis
On Linux/x86_64,
a1ecc5600464f6a62faab246d522b6328badda90 is the first bad commit
commit a1ecc5600464f6a62faab246d522b6328badda90
Author: liuhongt
Date: Wed Nov 23 21:58:09 2022 +0800
Fix incorrect _mm_cvtsbh_ss.
caused
FAIL: g++.dg/other/pr39060.C -std=c++98 (internal compiler error: c
On 11/25/22 17:18, Martin Liška wrote:
On 11/21/22 11:02, Jakub Jelinek wrote:
Otherwise LGTM. Thanks and sorry for the review delay.
Yuri, do you want to commit the patch soon?
If not, I can help if you want?
Hey.
I've just installed the patch with function signature change
and changelog
PING^4
On 4/7/22 16:00, Martin Liška wrote:
PING^3
On 3/24/22 11:22, Martin Liška wrote:
PING^2
On 3/4/22 14:47, Martin Liška wrote:
PING^1
On 1/26/22 12:11, Martin Liška wrote:
Hello.
Right now, switch lowering does not update basic_block::count values
so that they are uninitiliazed. Mor
On Mon, 28 Nov 2022 at 06:02, François Dumont via Libstdc++ <
libstd...@gcc.gnu.org> wrote:
> libstdc++: [_GLIBCXX_INLINE_VERSION] Adapt dg error messages
>
> libstdc++-v3/ChangeLog
>
> * testsuite/20_util/bind/ref_neg.cc: Adapt dg-prune-output
> message.
> * testsuite/20_util/fu
On Mon, 28 Nov 2022 at 10:06, Jonathan Wakely wrote:
>
>
> On Mon, 28 Nov 2022 at 06:02, François Dumont via Libstdc++ <
> libstd...@gcc.gnu.org> wrote:
>
>> libstdc++: [_GLIBCXX_INLINE_VERSION] Adapt dg error messages
>>
>> libstdc++-v3/ChangeLog
>>
>> * testsuite/20_util/bind/ref_neg.c
On Mon, 28 Nov 2022 at 06:07, François Dumont via Libstdc++ <
libstd...@gcc.gnu.org> wrote:
> This patch is fixing those tests:
>
> 20_util/to_chars/float128_c++23.cc
> std/format/formatter/requirements.cc
> std/format/functions/format.cc
> std/format/functions/format_to_n.cc
> std/format/function
This shows another case where trying to validate conversions during
the CHREC SCC analysis fails because said analysis assumes we are
converting a complete SCC. Like the constraint on the initial
conversion seen restrict all conversions handled to sign-changes.
Bootstrapped and tested on x86_64-u
On Mon, 28 Nov 2022 at 10:10, Jonathan Wakely wrote:
>
>
> On Mon, 28 Nov 2022 at 06:07, François Dumont via Libstdc++ <
> libstd...@gcc.gnu.org> wrote:
>
>> This patch is fixing those tests:
>>
>> 20_util/to_chars/float128_c++23.cc
>> std/format/formatter/requirements.cc
>> std/format/functions/
On 11/25/22 14:03, Torbjorn SVENSSON wrote:
Hi,
Ping, https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606528.html
ok, thanks!
Kind regards,
Torbjörn
On 2022-11-17 14:20, Torbjörn SVENSSON wrote:
v1 -> v2:
Paths without "C:" part can still be absolute if they start with / or
\ on W
On Mon, 21 Nov 2022 at 14:37, Prathamesh Kulkarni
wrote:
>
> On Fri, 4 Nov 2022 at 14:00, Prathamesh Kulkarni
> wrote:
> >
> > On Mon, 31 Oct 2022 at 15:27, Richard Sandiford
> > wrote:
> > >
> > > Prathamesh Kulkarni writes:
> > > > On Wed, 26 Oct 2022 at 21:07, Richard Sandiford
> > > > wrot
Le 27/11/2022 à 21:32, Harald Anlauf via Fortran a écrit :
Dear Fortranners,
in dependency checking of arguments of elemental prodecures
we should treat dummy arguments with the value attribute as
implicitly having intent(in). This is simple and obvious.
The PR by Gerhard provides a series of
Hi,
please have a look at the patch below for a potential fix that addresses the
incorrect 'promotion'
of members found in temporaries within co_await statements.
To summarize my post in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99576#c5,
the recursive
promotion of temporaries is too eager a
From: Yannick Moy
SPARK RM 7.1.4(4) does not mandate anymore that a package with abstract
states has a completing body, unless the package state is mentioned in
Part_Of specifications. Implement that change.
gcc/ada/
* sem_prag.adb (Check_Part_Of_Abstract_State): Add verification
From: Eric Botcazou
The problem is that the regular expansion of the conversion around the
call to the subprogram is disabled by the expansion of the validity check
around the same call, as documented in Expand_Actuals:
-- This case is given higher priority because the subsequent check
--
From: Claire Dross
So it can be used safely from SPARK code. The abstract state represents
the source code information that is accessed by the functions defined
in Source_Info. It is volatile as it is updated asyncronously when
moving in the code.
gcc/ada/
* libgnat/g-souinf.ads (Source
From: Eric Botcazou
gcc/ada/
* adaint.c [Linux]: Include .
(__gnat_get_executable_load_address) [Linux]: Enable.
Tested on x86_64-pc-linux-gnu, committed on master.
---
gcc/ada/adaint.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/gcc/ada/adaint.c
From: Joel Brobecker
This commit adjust the sphinx configuration to use the "Read The Docs"
theme, which has the advantage of allowing the navigation bar
(containing among other things a search bar, and the TOC) to stay
fixed while scrolling the contents of the page being read. This is
particular
From: Eric Botcazou
gcc/ada/
* libgnat/g-traceb.ads: Minor tweaks in the commentary.
(Executable_Load_Address): New function.
* doc/gnat_ugn/gnat_and_program_execution.rst (Non-Symbolic
Traceback): Adjust to PIE default on Linux.
(Symbolic Traceback): Like
On 11/15/22 15:51, Andre Vieira (lists) wrote:
On 11/11/2022 17:40, Stam Markianos-Wright via Gcc-patches wrote:
Hi all,
This is the 2/2 patch that contains the functional changes needed
for MVE Tail Predicated Low Overhead Loops. See my previous email
for a general introduction of MVE LOLs.
For __builtin_ia32_vec_set_v16qi (a, -1, 2) with
!flag_signed_char. it's transformed to
__builtin_ia32_vec_set_v16qi (_4, 255, 2) in the gimple,
and expanded to (const_int 255) in the rtl. But for immediate_operand,
it expects (const_int 255) to be signed extended to
(const_int -1). The mismatch ca
On Mon, 28 Nov 2022 at 10:08, Jonathan Wakely wrote:
>
>
> On Mon, 28 Nov 2022 at 10:06, Jonathan Wakely wrote:
>
>>
>>
>> On Mon, 28 Nov 2022 at 06:02, François Dumont via Libstdc++ <
>> libstd...@gcc.gnu.org> wrote:
>>
>>> libstdc++: [_GLIBCXX_INLINE_VERSION] Adapt dg error messages
>>>
>>> li
The check for HAVE_LD_RO_RW_SECTION_MIXING fails on targets where ld
does not support shared objects, even though the answer to the test
should be 'read-write'. One such target is riscv64-unknown-elf. Failing
this test results in a libgcc crtbegin.o which has a writable .eh_frame
section leading to
When CPLUSPLUS_CPP_SPEC is set to a string literal it is not possible to
modify it through external spec files by renaming the original cpp spec
and replacing it because the compiler cpp_spec will still point to the
original, renamed cpp spec. Not defining CPLUSPLUS_CPP_SPEC makes gcc.cc
fall back
From: Ju-Zhe Zhong
gcc/ChangeLog:
* config/riscv/riscv-protos.h (enum vlmul_type): New enum.
(get_vlmul): New function.
(get_ratio): Ditto.
* config/riscv/riscv-v.cc (struct mode_vtype_group): New struct.
(ENTRY): Adapt for attributes.
(enum vlmul_
On Mon, Nov 28, 2022 at 11:37:34AM +0800, Jiufu Guo wrote:
> Segher Boessenkool writes:
> > On Fri, Nov 25, 2022 at 04:11:49PM +0800, Kewen.Lin wrote:
> >> on 2022/10/26 19:40, Jiufu Guo wrote:
> >> for "li/lis + oris/xoris", I interpreted it into four combinations:
> >>
> >>li + oris, lis +
From: Ju-Zhe Zhong
Since mask instruction doesn't need policy, so remove it to make it look
reasonable.
gcc/ChangeLog:
* config/riscv/vector.md: Remove TA && MA operands.
---
gcc/config/riscv/vector.md | 2 --
1 file changed, 2 deletions(-)
diff --git a/gcc/config/riscv/vector.md b/g
On 11/11/22 02:26, liuhongt via Gcc-patches wrote:
2 years ago, ARM folks support HWASAN[1] in GCC[2], and introduced several
target hooks(Many thanks to their work) so other backends can do similar
things if they have similar feature.
Intel LAM(linear Address Masking)[3 Charpter 14] suppor
> "Joel" == Joel Brobecker via Gdb-patches
> writes:
Joel> ChangeLog:
Joel> * src-release.sh (GDB_SUPPORT_DIRS): Add libsframe.
Joel> Ok to apply to master?
Looks good to me.
I think we recently agreed that gdb and binutils maintainers can approve
patches like this... ?
thank
On 11/25/22 07:07, Maciej W. Rozycki wrote:
Hi Kito,
On Fri, 12 Aug 2022, Maciej W. Rozycki wrote:
LGTM, but with a nit, I don't get set.w but get an andi like below, so
maybe we should also scan-assembler-not andi? feel free to commit that
directly with that fix
```asm
sleu:
sgtu
Tested x86_64-linux. Pushed to trunk.
-- >8 --
This implements the proposed resolution of LWG 3809, so that
std::subtract_with_carry_engine can be used with a 16-bit result_type.
Currently this produces a narrowing error when instantiating the
std::linear_congruential_engine to create the initial
Tested x86_64-linux. Pushed to trunk.
-- >8 --
This means we don't need to use "(__8::)?" in dg-prune-output
directives.
libstdc++-v3/ChangeLog:
* testsuite/20_util/is_complete_or_unbounded/memoization_neg.cc:
Simplify dg-prune-output pattern.
* testsuite/lib/prune.exp (
On Mon, 28 Nov 2022 at 15:20, Jonathan Wakely via Libstdc++ <
libstd...@gcc.gnu.org> wrote:
> Tested x86_64-linux. Pushed to trunk.
>
I didn't notice until my mailer flagged it that this commit has a non-ASCII
character. Fixed by the attached patch, pushed to trunk.
commit c775e2b81fca39f366040d4
scan-assembler-not sext\\.w
FAIL: gcc.target/riscv/sleu.c -O1 scan-assembler-not sext\\.w
FAIL: gcc.target/riscv/sleu.c -Og -g scan-assembler-not sext\\.w
when applied on top of:
$ riscv64-linux-gnu-gcc --version
riscv64-linux-gnu-gcc (GCC) 13.0.0 20221128 (experimental)
Not anymore with th
On 11/27/22 19:14, Feng Wang wrote:
From: wangfeng
There is no Immediate operand of ins "rol" accroding to the B-ext,
so the immediate operand should be loaded into register at first.
But we can convert it to the ins "rori" or "roriw", and then one
immediate load ins can be reduced.
Please r
Hi,
On Wed, Nov 16 2022, Jan Hubicka wrote:
>> IPA-CP transformation summary streaming code currently won't stream
>> out transformations necessary for clones which are only necessary for
>> materialization of other clones (such as an IPA-CP clone which is then
>> cloned again by IPA-SRA). Howeve
On 2022-11-28 12:21, Nathan Sidwell wrote:
On 11/25/22 14:03, Torbjorn SVENSSON wrote:
Hi,
Ping, https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606528.html
ok, thanks!
Pushed.
Kind regards,
Torbjörn
On 2022-11-17 14:20, Torbjörn SVENSSON wrote:
v1 -> v2:
Paths without "C:
Hi Richard,
On 25/11/2022 21:08, Richard Biener via Gcc-patches wrote:
>
>
> On Fri, 25 Nov 2022, Vaseeharan Vinayagamoorthy wrote:
>
> > Hi,
> >
> > I am seeing an internal compiler error, related to this patch:
>
> Can you please open a bugzilla for this and attach preprocessed
> source so
On 11/28/22 08:38, Maciej W. Rozycki wrote:
On Mon, 28 Nov 2022, Jeff Law wrote:
LGTM, but with a nit, I don't get set.w but get an andi like below, so
maybe we should also scan-assembler-not andi? feel free to commit that
directly with that fix
```asm
sleu:
sgtua0,a0,a1
On 11/28/22 07:14, juzhe.zh...@rivai.ai wrote:
From: Ju-Zhe Zhong
gcc/ChangeLog:
* config/riscv/riscv-protos.h (enum vlmul_type): New enum.
(get_vlmul): New function.
(get_ratio): Ditto.
* config/riscv/riscv-v.cc (struct mode_vtype_group): New struct.
On 11/28/22 07:21, juzhe.zh...@rivai.ai wrote:
From: Ju-Zhe Zhong
Since mask instruction doesn't need policy, so remove it to make it look
reasonable.
gcc/ChangeLog:
* config/riscv/vector.md: Remove TA && MA operands.
Does this fix a known bug or is it just a cleanup? I think t
On 11/25/22 09:06, juzhe.zh...@rivai.ai wrote:
From: Ju-Zhe Zhong
gcc/ChangeLog:
* config/riscv/constraints.md (Wdm): New constraint.
* config/riscv/predicates.md (direct_broadcast_operand): New predicate.
* config/riscv/riscv-protos.h (RVV_VLMAX): New macro.
On 11/28/22 06:59, Joakim Nohlgård wrote:
The check for HAVE_LD_RO_RW_SECTION_MIXING fails on targets where ld
does not support shared objects, even though the answer to the test
should be 'read-write'. One such target is riscv64-unknown-elf. Failing
this test results in a libgcc crtbegin.o whi
On 11/27/22 22:28, Fei Gao wrote:
In current riscv stack frame allocation, 2 steps are used. The first step
allocates memories at least for callee saved GPRs and FPRs, and the second step
allocates the rest if stack size is greater than signed 12-bit range. But it's
observed in some cases, l
Tested x86_64-linux, built on msp430-elf and h8300-elf. Pushed to trunk.
-- >8 --
For H8/300 size_t is 32 bits wide, but (unsigned char)buf[2] << 16
promotes to int which is only 16 bits wide. The shift is then undefined.
This fixes it by converting to size_t before shifting.
libstdc++-v3/Change
Tested x86_64-linux, built on msp430-elf and h8300-elf. Pushed to trunk.
-- >8 --
This fixes compilation failures for H8 multilibs. For the normal
multilib (ILP16L32?), the chunk struct does not have the expected size,
because uint32_t is type long and has alignment 4 (by default). This
forces si
On 11/22/22 19:58, Jiufu Guo wrote:
Hi Jeff,
Thanks a lot for your comments!
Jeff Law writes:
On 11/20/22 20:07, Jiufu Guo wrote:
Jiufu Guo writes:
Hi,
As mentioned in the previous version patch:
https://gcc.gnu.org/pipermail/gcc-patches/2022-October/604646.html
The suboptimal code is
Tested x86_64-linux, built on msp430-elf and h8300-elf. Pushed to trunk.
-- >8 --
For H8/300 with -msx -mn -mint32 the type of (_M_len - __pos) is int,
because int is wider than size_t so the operands are promoted.
libstdc++-v3/ChangeLog:
* include/std/string_view (basic_string_view::co
On Mon, Nov 28, 2022 at 03:51:59PM +0800, Jiufu Guo wrote:
> Jiufu Guo via Gcc-patches writes:
> > Segher Boessenkool writes:
> >>> > + else
> >>> > + {
> >>> > + emit_move_insn (temp,
> >>> > + GEN_INT (((ud2 << 16) ^ 0x8000) -
> >>> > 0x8000))
On 9/1/22 03:41, Даниил Александрович Фролов via Gcc-patches wrote:
Subject:
Re: -Wformat-overflow handling for %b and %B directives in C2X standard
From:
Даниил Александрович Фролов via Gcc-patches
Date:
9/1/22, 03:41
To:
Marek Polacek
CC:
"gcc-patches@gcc.gnu.org"
From eb9e8241d991450
On 1/26/22 04:11, Martin Liška wrote:
Hello.
Right now, switch lowering does not update basic_block::count values
so that they are uninitiliazed. Moreover, I've updated probability scaling
when a more complex expansion happens. There are still some situations
where
the profile is a bit impre
We produce inefficient code for some synthesized SImode conditional set
operations (i.e. ones that are not directly implemented in hardware) on
RV64. For example a piece of C code like this:
int
sleu (unsigned int x, unsigned int y)
{
return x <= y;
}
gets compiled (at `-O2') to this:
sleu:
On 9/16/22 07:52, Jason Merrill wrote:
On 6/24/22 01:23, Alexandre Oliva via Gcc-patches wrote:
On Jun 23, 2022, Alexandre Oliva wrote:
Here's the patch. Regstrapped on x86_64-linux-gnu, also tested with a
cross to aarch64-rtems6. Ok to install?
Introduce -nostdlib++ option
Uhh, I went
On Mon, Nov 28, 2022 at 09:42:05AM +0100, Richard Biener wrote:
> Since the function seems to be allowed to fail the patch looks
> reasonable - still I wonder
> what the "fallback" for a MODE_CC style compare-and-branch is? There
> are callers
> of this function that do not seem to expect failure
On 28/11/22 14:39, Jonathan Wakely wrote:
On Mon, 28 Nov 2022 at 10:08, Jonathan Wakely wrote:
On Mon, 28 Nov 2022 at 10:06, Jonathan Wakely
wrote:
On Mon, 28 Nov 2022 at 06:02, François Dumont via Libstdc++
mailto:libstdc%2b...@gcc.gnu.org>> wrote:
On Mon, 28 Nov 2022 08:44:16 PST (-0800), jeffreya...@gmail.com wrote:
On 11/28/22 07:14, juzhe.zh...@rivai.ai wrote:
From: Ju-Zhe Zhong
gcc/ChangeLog:
* config/riscv/riscv-protos.h (enum vlmul_type): New enum.
(get_vlmul): New function.
(get_ratio): Ditto.
On 11/28/22 10:44, Maciej W. Rozycki wrote:
Your patch is probably still useful. I think Kito's only concern was to make
sure we don't have the ANDI instruction in addition to not having the SEXT
instruction. So still approved for trunk, just update the testcases to make
sure we don't hav
On Mon, 28 Nov 2022 at 06:07, François Dumont via Libstdc++ <
libstd...@gcc.gnu.org> wrote:
> This patch is fixing those tests:
>
> 20_util/to_chars/float128_c++23.cc
> std/format/formatter/requirements.cc
> std/format/functions/format.cc
> std/format/functions/format_to_n.cc
> std/format/function
The following avoids ICEing for V2SI -> DImode vec_unpacks_lo.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR tree-optimization/107896
* tree-vect-stmts.cc (supportable_widening_operation):
Handle non-vector mode intermediate mode.
---
gcc/tree-vect-stmts
On 28/11/22 11:21, Jonathan Wakely wrote:
On Mon, 28 Nov 2022 at 10:10, Jonathan Wakely wrote:
On Mon, 28 Nov 2022 at 06:07, François Dumont via Libstdc++
mailto:libstdc%2b...@gcc.gnu.org>> wrote:
This patch is fixing those tests:
20_util/to_chars/float128_c++23.cc
I forgot to add the patch but as you already made another feedback I'll
clean my patch first.
On 28/11/22 19:43, François Dumont wrote:
On 28/11/22 11:21, Jonathan Wakely wrote:
On Mon, 28 Nov 2022 at 10:10, Jonathan Wakely wrote:
On Mon, 28 Nov 2022 at 06:07, François Dumont via Li
On Fri, 18 Nov 2022 09:01:08 PST (-0800), Palmer Dabbelt wrote:
On Thu, 17 Nov 2022 22:59:08 PST (-0800), Kito Cheng wrote:
Wait, what's Xgnuzihintpausestate???
I just made it up, it's defined right next to the name like those
profile extensions are. I figured that's the most RISC-V way to de
On Mon, Nov 28, 2022 at 6:58 PM Segher Boessenkool
wrote:
>
> On Mon, Nov 28, 2022 at 09:42:05AM +0100, Richard Biener wrote:
> > Since the function seems to be allowed to fail the patch looks
> > reasonable - still I wonder
> > what the "fallback" for a MODE_CC style compare-and-branch is? There
On 11/24/22 00:43, Sinan wrote:
The motivation of this patch is to correct the wrong estimation of
the number of instructions needed for loading a 64bit constant in
rv32 in the current cost model(riscv_interger_cost). According to
the current implementation, if a constant requires more th
On Mon, 28 Nov 2022 11:15:01 PST (-0800), gcc-patches@gcc.gnu.org wrote:
>
>
> On 11/24/22 00:43, Sinan wrote:
>>> The motivation of this patch is to correct the wrong estimationÂ
>>>of
 the number of instructions needed for loading a 64bit constantÂ
in
 rv32 in
On Mon, 28 Nov 2022, Jeff Law wrote:
> > Given the false negatives how about getting a bit stricter and also
> > checking there's nothing following the XORI instruction, like here?
> >
> > It might be an overkill to have a check both for the sequence and for the
> > absence of ANDI or SEXT.W
On 11/10/22 07:37, Lin Sinan via Gcc-patches wrote:
The motivation of this patch is to correct the wrong estimation of the number
of instructions needed for loading a 64bit constant in rv32 in the current cost
model(riscv_interger_cost). According to the current implementation, if a
constant
Dear all,
as reported, the Fortran standard requires all actual argument
expressions to be evaluated (e.g. F2018:15.5.3).
There were two cases for intrinsic MERGE where we failed to do so:
- non-constant mask; Steve provided the patch
- constant scalar mask; we need to be careful to simplify on
From: Andrew Pinski
There was a small typo where Also was done
twice. The second also should have been
handled. This fixes that.
Committed as obvious after a build.
gcc/ChangeLog:
* match.pd ((A / (1 << B)) -> (A >> B).):
Fix comment.
---
gcc/match.pd | 2 +-
1 file changed, 1
Here we're crashing when using an explicit specialization of a function
template with trailing requirements ultimately because decls_match
(called indirectly from register_specialization) returns false since the
template has trailing requirements whereas the specialization doesn't.
In r12-2230-gdd
On 28/11/22 19:35, Jonathan Wakely wrote:
On Mon, 28 Nov 2022 at 06:07, François Dumont via Libstdc++
mailto:libstdc%2b...@gcc.gnu.org>> wrote:
This patch is fixing those tests:
20_util/to_chars/float128_c++23.cc
std/format/formatter/requirements.cc
std/format/functions/form
Hi Adrian,
Again thanks for working on this and getting it into a suitable state for
posting.
It’s a good idea to CC relevant maintainer(s) on patches [see MAINTAINERS] and
I’d welcome cc on any coroutines ones (it’s easy to miss a patch otherwise).
> On 28 Nov 2022, at 11:55, Adrian Perl via G
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
Some clang folks mailed me asking about being less permissive about
'concept bool', so let's bump it up from pedwarn to permerror.
gcc/cp/ChangeLog:
* parser.cc (cp_parser_decl_specifier_seq): Change 'concept bool'
diagnost
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
Usually a requirement starting with 'typename' is a type-requirement, but it
might be a simple-requirement such as a functional cast to a typename-type.
PR c++/101733
gcc/cp/ChangeLog:
* parser.cc (cp_parser_requirement):
On Mon, Mar 7, 2022 at 6:06 AM Jakub Jelinek via Gcc-patches
wrote:
>
> Hi!
>
> Like in r10-7215-g700d4cb08c88aec37c13e21e63dd61fd698baabc 2 years ago,
> I've run
> grep -v 'long long\|optab optab\|template template\|double double'
> *.{[chS],cc} */*.{[chS],cc} *.def config/*/* 2>/dev/null | grep
[temp.res.general]/3 says, in a note, "the usual qualified name lookup
([basic.lookup.qual]) applies even in the presence of typename". Thus
when resolving a TYPENAME_TYPE, it seems we shouldn't be looking past
non-type members.
This patch fixes this by passing want_type=false instead of =true du
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_option_override): Fix comment
wording.
---
Just stumbled on this one looking at the output of that sed script. The
script itself was fine, the original comment was to blame.
---
gcc/config/riscv/riscv.cc | 2 +-
1 file changed, 1 inse
On Fri, 25 Nov 2022, Zopolis0 via Gcc-patches wrote:
> Firstly, to get feedback and reviews on the 56 already existing
> patches, even though most are just re-adding code or making idiomatic
> changes, so that when the final issue is solved everything has already
> been approved (hopefully) and th
>> I'm tempted to push this into the next stage1 given its arrival after
>> stage1 close, but if the wider RISC-V maintainers want to see it move
>> forward, I don't object strongly.
Ok, let's save these patches and merge them when GCC14 stage1 is open.
Would you mind telling me when will stage 1
Yes, it's a cleanup.
juzhe.zh...@rivai.ai
From: Jeff Law
Date: 2022-11-29 00:48
To: juzhe.zhong; gcc-patches
CC: kito.cheng; palmer
Subject: Re: [PATCH] RISC-V: Remove tail && mask policy operand for vmclr,
vmset, vmld, vmst
On 11/28/22 07:21, juzhe.zh...@rivai.ai wrote:
> From: Ju-Zhe Zhon
OK.
juzhe.zh...@rivai.ai
From: Jeff Law
Date: 2022-11-29 00:49
To: juzhe.zhong; gcc-patches
CC: kito.cheng
Subject: Re: [PATCH] RISC-V: Add duplicate vector support.
On 11/25/22 09:06, juzhe.zh...@rivai.ai wrote:
> From: Ju-Zhe Zhong
>
> gcc/ChangeLog:
>
> * config/riscv/constraint
On Mon, Nov 28, 2022 at 07:46:07PM +0100, Richard Biener wrote:
> Anyhow - my question still stands - what's the fallback for the callers
> that do not check for failure? How are we sure we're not running into
> these when relaxing the requirement that a MODE_CC prepare_cmp_insn
> must not fail?
Thanks.
I think we still can continue RVV feature reviewing process in github branch
that we have talked about. Such patches that have been reviewed I will still
send
them to GCC mail list and not to merge right now, we can wait until stage1 is
open.
Is it a good idea ? I don't want to make RV
On Mon, 28 Nov 2022 15:10:15 PST (-0800), juzhe.zh...@rivai.ai wrote:
Thanks.
I think we still can continue RVV feature reviewing process in github branch
that we have talked about. Such patches that have been reviewed I will still
send
them to GCC mail list and not to merge right now, we can
On 11/28/22 15:16, Patrick Palka wrote:
Here we're crashing when using an explicit specialization of a function
template with trailing requirements ultimately because decls_match
(called indirectly from register_specialization) returns false since the
template has trailing requirements whereas th
On 11/28/22 15:52, 钟居哲 wrote:
>> I'm tempted to push this into the next stage1 given its arrival after
stage1 close, but if the wider RISC-V maintainers want to see it move
forward, I don't object strongly.
Ok, let's save these patches and merge them when GCC14 stage1 is open.
Would you mi
On Mon, 28 Nov 2022, Patrick Palka wrote:
> [temp.res.general]/3 says, in a note, "the usual qualified name lookup
> ([basic.lookup.qual]) applies even in the presence of typename". Thus
> when resolving a TYPENAME_TYPE, it seems we shouldn't be looking past
> non-type members.
>
> This patch fi
Hi!
On Sat, Nov 26, 2022 at 09:16:13PM -0500, Charlie Sale via Gcc-patches wrote:
> This is my first contribution to GCC :) one of the beginner projects
> suggested on the website was to add and use RTL type predicates.
It says "See which ones are worth having a predicate for, and add them."
Non
On Sun, Nov 27, 2022 at 09:21:00AM -0500, David Malcolm via Gcc-patches wrote:
> We're currently in "stage 3" of GCC 13 development, which means that
> we're focusing on bug-fixing, rather than cleanups and feature work.
> Though exceptions can be made for low-risk work, at the discretion of
> the
Hello,
this series addresses the long standing issue with xtensa configuration
support by adding a way to configure toolchain for a specific xtensa
core at runtime using the xtensa-dynconfig [1] library as a plugin.
On a platform with shared library support single toolchain binary
becomes capable
Now that gcc provides __XCHAL_* definitions use them instead of XCHAL_*
definitions from the include/xtensa-config.h. That makes libgcc
dynamically configurable for the target xtensa core.
libgcc/
* config/xtensa/crti.S (xtensa-config.h): Replace #inlcude with
xtensa-config-builtin
Import include/xtensa-dynconfig.h that defines XCHAL_* macros as fields
of a structure returned from the xtensa_get_config_v function call.
Define that structure and fill it with default parameter values
specified in the include/xtensa-config.h.
Define reusable function xtensa_load_config that trie
Hi Richard,
在 2022/11/29 2:46, Richard Biener 写道:
> Anyhow - my question still stands - what's the fallback for the callers
> that do not check for failure? How are we sure we're not running into
> these when relaxing the requirement that a MODE_CC prepare_cmp_insn
> must not fail?
I examed the
1 - 100 of 114 matches
Mail list logo
