Hi all,
The attached log entry and patch (git show) fixes this issue by adding
logic to handle spaces in eat_separators. One or more spaces by
themselves are a valid separator. So in this case we look at the
character following the spaces to see if it is a comma or semicolon.
If so, I
Alex Coplan writes:
> On 23/02/2024 16:41, Ajit Agarwal wrote:
>> Hello Richard/Alex/Segher:
>
> Hi Ajit,
>
> Sorry for the delay and thanks for working on this.
>
> Generally this looks like the right sort of approach (IMO) but I've left
> some comments below.
>
> I'll start with a meta comment:
On 4/3/24 15:16, Jakub Jelinek wrote:
On Wed, Apr 03, 2024 at 12:58:12PM -0400, Jason Merrill wrote:
On 4/3/24 12:42, Jakub Jelinek wrote:
On Wed, Apr 03, 2024 at 12:07:48PM -0400, Jason Merrill wrote:
Using std::is_constant_evaluated directly in a loop condition is, as the
paper says,
We assume that TYPE_NO_NAMED_ARGS_STDARG_P don't have any named arguments and
there is nothing to advance, but that is not the case for (...) functions
returning by hidden reference which have one such artificial argument.
This causes gcc.dg/c23-stdarg-[68].c to fail
Fix the issue by checking if
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the Swedish team of translators. The file is available at:
https://translationproject.org/latest/gcc/sv.po
(This file,
On Wed, Apr 03, 2024 at 12:58:12PM -0400, Jason Merrill wrote:
> On 4/3/24 12:42, Jakub Jelinek wrote:
> > On Wed, Apr 03, 2024 at 12:07:48PM -0400, Jason Merrill wrote:
> > > Using std::is_constant_evaluated directly in a loop condition is, as the
> > > paper says, unlikely and "horrendous code",
On 3/28/24 08:22, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
The testcase in comment 15 of the linked PR is caused because the
following assumption in depset::hash::make_dependency doesn't hold:
if (DECL_LANG_SPECIFIC (not_tmpl)
On 4/2/24 13:52, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/13?
-- >8 --
We evaluate constexpr functions on the original, pre-genericization bodies.
That means that the function body we're evaluating will not have gone
through cp_genericize_r's "Map block
On 4/3/24 12:42, Jakub Jelinek wrote:
On Wed, Apr 03, 2024 at 12:07:48PM -0400, Jason Merrill wrote:
Using std::is_constant_evaluated directly in a loop condition is, as the
paper says, unlikely and "horrendous code", so I'm not concerned about
surprising effects, though I guess we should check
On Wed, Apr 03, 2024 at 12:07:48PM -0400, Jason Merrill wrote:
> Using std::is_constant_evaluated directly in a loop condition is, as the
> paper says, unlikely and "horrendous code", so I'm not concerned about
> surprising effects, though I guess we should check for it with
>
On 4/3/24 10:45 AM, Andrew Pinski wrote:
> On Wed, Apr 3, 2024 at 8:32 AM Peter Bergner wrote:
> I think you misunderstood the patch/situtation. Most ifunc resolves
> don't use TLS at all; what is happening here is that the profiler
> (-fprofile-generate) is adding TLS usage to the ifunc resolver
On 4/3/24 03:25, Jakub Jelinek wrote:
Hi!
The following patch attempts to implement P2809R3, which has been voted
in as a DR.
The middle-end has its behavior documented:
'-ffinite-loops'
Assume that a loop with an exit will eventually take the exit and
not loop indefinitely. This
On Wed, Apr 3, 2024 at 8:32 AM Peter Bergner wrote:
>
> On 4/3/24 7:40 AM, H.J. Lu wrote:
> > We can't profile indirect calls to IFUNC resolvers nor their callees as
> > it requires TLS which hasn't been set up yet when the dynamic linker is
> > resolving IFUNC symbols.
> >
> > Add an IFUNC
On Wed, Apr 3, 2024 at 8:31 AM Peter Bergner wrote:
>
> On 4/3/24 7:40 AM, H.J. Lu wrote:
> > We can't profile indirect calls to IFUNC resolvers nor their callees as
> > it requires TLS which hasn't been set up yet when the dynamic linker is
> > resolving IFUNC symbols.
> >
> > Add an IFUNC
LoongArch added an -mtls-dialect option, causing the similarly
named option for i386 get renumbered.
Fixes: b253b4695dda ("LoongArch: Add support for TLS descriptors.")
gcc/ChangeLog:
* config/i386/i386.opt.urls: Regenerate.
---
Pushed as obvious.
gcc/config/i386/i386.opt.urls | 2 +-
On Tue, 2 Apr 2024, Martin Uecker wrote:
> Am Dienstag, dem 02.04.2024 um 20:42 + schrieb Joseph Myers:
> > On Tue, 2 Apr 2024, Martin Uecker wrote:
> >
> > > [C23]fix aliasing for structures/unions with incomplete types
> > >
> > > When incomplete structure/union types are completed later,
On 4/3/24 7:40 AM, H.J. Lu wrote:
> We can't profile indirect calls to IFUNC resolvers nor their callees as
> it requires TLS which hasn't been set up yet when the dynamic linker is
> resolving IFUNC symbols.
>
> Add an IFUNC resolver caller marker to cgraph_node and set it if the
> function is
On 23/02/2024 16:41, Ajit Agarwal wrote:
> Hello Richard/Alex/Segher:
Hi Ajit,
Sorry for the delay and thanks for working on this.
Generally this looks like the right sort of approach (IMO) but I've left
some comments below.
I'll start with a meta comment: in the subject line you have marked
On 4/2/24 20:57, Nathaniel Shead wrote:
On Tue, Apr 02, 2024 at 01:18:17PM -0400, Jason Merrill wrote:
On 3/28/24 23:21, Nathaniel Shead wrote:
- && !(modules_p () && DECL_DECLARED_INLINE_P (fn)))
+ && !(modules_p ()
+ && (DECL_DECLARED_INLINE_P (fn)
+
On Wed, Apr 3, 2024 at 6:38 AM Jan Hubicka wrote:
>
> > We can't profile indirect calls to IFUNC resolvers nor their callees as
> > it requires TLS which hasn't been set up yet when the dynamic linker is
> > resolving IFUNC symbols.
> >
> > Add an IFUNC resolver caller marker to cgraph_node and
> We can't profile indirect calls to IFUNC resolvers nor their callees as
> it requires TLS which hasn't been set up yet when the dynamic linker is
> resolving IFUNC symbols.
>
> Add an IFUNC resolver caller marker to cgraph_node and set it if the
> function is called by an IFUNC resolver.
On Wed, 3 Apr 2024, Tobias Burnus wrote:
> Found when working with -save-temps and looking at 'mkoffload'
> with a GCC configured for both nvptx and gcn offloading.
>
> Before (for 'a.out') for mkoffload:a.offload_args now:
> a.amdgcn-amdhsa.offload_args and a.nvptx-none.offload_args
> OK for
On Tue, Apr 2, 2024 at 10:03 AM Jan Hubicka wrote:
>
> > > I am bit worried about commonly used functions getting "infected" by
> > > being called once from ifunc resolver. I think we only use thread local
> > > storage for indirect call profiling, so we may just disable indirect
> > > call
We can't profile indirect calls to IFUNC resolvers nor their callees as
it requires TLS which hasn't been set up yet when the dynamic linker is
resolving IFUNC symbols.
Add an IFUNC resolver caller marker to cgraph_node and set it if the
function is called by an IFUNC resolver. Disable indirect
on 2024/4/3 19:18, Jakub Jelinek wrote:
> On Wed, Apr 03, 2024 at 07:01:50PM +0800, Kewen.Lin wrote:
>> Thanks for the details on debugging support, but IIUC with this workaround
>> being adopted, the debuggability on hidden args are already broken, aren't?
>
> No.
> In the correct program case,
Nvptx's mkoffload.cc contains 14 'fatal_error' calls and one 'warning_at' call,
which stands out more clearly (color, bold) when enabling
diagnostic_color_init
which this patch does. — Additionally, the call gcc_init_libintl permits that
the already translated error messages also show up as
On Thu, Mar 28, 2024 at 4:03 AM Eugene Rozenfeld
wrote:
>
> auto-profile currently doesn't guarantee that it will set probabilities
> on all edges because of zero basic block counts. Normally those edges
> just have probabilities set by the preceding profile_estimate pass but
> under -O0
Found when working with -save-temps and looking at 'mkoffload'
with a GCC configured for both nvptx and gcn offloading.
Before (for 'a.out') for mkoffload:a.offload_args now: a.amdgcn-amdhsa.offload_args
and a.nvptx-none.offload_args
OK for mainline?
Tobias
PS: The code does not free the
Hi Richard, Thomas,
On 2023/10/30 8:46 PM, Richard Biener wrote:
>>
>> What Chung-Lin's first patch does is mark the OMP clause for 'x' (not the
>> 'x' decl itself!) as 'readonly', via a new 'OMP_CLAUSE_MAP_READONLY'
>> flag.
>>
>> The actual optimization then is done in this second patch.
On 03/04/2024 10:27, Jakub Jelinek wrote:
On Wed, Apr 03, 2024 at 11:09:19AM +0200, Tobias Burnus wrote:
@@ -3954,8 +3956,8 @@ on the GPU.
To enable support for GCN3 Fiji devices (gfx803), GCC has to be configured
with
@option{--with-arch=@code{fiji}} or
On Wed, Apr 03, 2024 at 07:01:50PM +0800, Kewen.Lin wrote:
> Thanks for the details on debugging support, but IIUC with this workaround
> being adopted, the debuggability on hidden args are already broken, aren't?
No.
In the correct program case, which should be the usual case, the caller will
The following avoids re-walking and re-combining the instructions
between i2 and i3 when the pattern of i2 doesn't change.
Bootstrap and regtest running ontop of a reversal of
r14-9692-g839bc42772ba7a.
It brings down memory use frmo 9GB to 400MB and compile-time from
80s to 3.5s.
Hi!
on 2024/4/3 17:23, Jakub Jelinek wrote:
> On Wed, Apr 03, 2024 at 05:02:40PM +0800, Kewen.Lin wrote:
>> on 2024/4/3 16:35, Jakub Jelinek wrote:
>>> On Wed, Apr 03, 2024 at 01:18:54PM +0800, Kewen.Lin wrote:
> I'd prefer not to remove DECL_ARGUMENTS chains, they are valid arguments
>
Tested x86_64-linux. Pushed to trunk. Backports likely to follow.
-- >8 --
This is a workaround for a possible compiler bug that causes constraint
recursion in the operator<=>(const optional&, const U&) overload.
libstdc++-v3/ChangeLog:
PR libstdc++/104606
*
Hi Jakub, hello world
Jakub Jelinek wrote:
On Wed, Apr 03, 2024 at 11:09:19AM +0200, Tobias Burnus wrote:
@@ -3954,8 +3956,8 @@ on the GPU.
To enable support for GCN3 Fiji devices (gfx803), GCC has to be configured
with
@option{--with-arch=@code{fiji}} or
On 03/04/2024 10:05, Tobias Burnus wrote:
This patch handles --with-arch= in GCN's mkoffload.cc
While mkoffload mostly does not know this and passes it through to the
GCN lto1 compiler,
it writes an .o file with debug information - and here the -march= in
the ELF flags must
agree with the one
Hi!
I'd like to ping the following patches:
https://gcc.gnu.org/pipermail/gcc-patches/2024-March/647445.html
PR111284 P2
https://gcc.gnu.org/pipermail/gcc-patches/2024-March/648215.html
PR114409 (part of a P1)
https://gcc.gnu.org/pipermail/gcc-patches/2024-March/648381.html
PR114426 P1
On Wed, 3 Apr 2024, Iain Sandoe wrote:
> Hi Richard,
>
> > On 7 Mar 2024, at 13:40, FX Coudert wrote:
> >
> >> I think it's an obvious change ...
> >
> > Thanks, pushed.
> >
> > Dimitry, I suggest you post the second patch for review.
>
> Given that the two patches here (for
>
On Wed, Apr 03, 2024 at 11:09:19AM +0200, Tobias Burnus wrote:
> @@ -3954,8 +3956,8 @@ on the GPU.
> To enable support for GCN3 Fiji devices (gfx803), GCC has to be configured
> with
> @option{--with-arch=@code{fiji}} or
> @option{--with-multilib-list=@code{fiji},...}. Note that support for
On Wed, Apr 03, 2024 at 05:02:40PM +0800, Kewen.Lin wrote:
> on 2024/4/3 16:35, Jakub Jelinek wrote:
> > On Wed, Apr 03, 2024 at 01:18:54PM +0800, Kewen.Lin wrote:
> >>> I'd prefer not to remove DECL_ARGUMENTS chains, they are valid arguments
> >>> that just some
> >>> invalid code doesn't pass.
Update for the GCN Newlib commit 7dd4eb1db "amdgcn: Implement proper locks",
https://sourceware.org/git/?p=newlib-cygwin.git;a=commit;h=7dd4eb1db
And change future to past tense regarding the LLVM 18 release.
OK for mainline?
Thanks,
Tobias
GCN: install.texi update for Newlib change and LLVM
This patch handles --with-arch= in GCN's mkoffload.cc
While mkoffload mostly does not know this and passes it through to the GCN lto1
compiler,
it writes an .o file with debug information - and here the -march= in the ELF
flags must
agree with the one in the other files. Hence, it uses now the
Hi Richard,
> On 7 Mar 2024, at 13:40, FX Coudert wrote:
>
>> I think it's an obvious change ...
>
> Thanks, pushed.
>
> Dimitry, I suggest you post the second patch for review.
Given that the two patches here (for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111632) were considered obvious
Hi Jakub,
on 2024/4/3 16:35, Jakub Jelinek wrote:
> On Wed, Apr 03, 2024 at 01:18:54PM +0800, Kewen.Lin wrote:
>>> I'd prefer not to remove DECL_ARGUMENTS chains, they are valid arguments
>>> that just some
>>> invalid code doesn't pass. By removing them you basically always create an
>>>
On Wed, Apr 03, 2024 at 01:18:54PM +0800, Kewen.Lin wrote:
> > I'd prefer not to remove DECL_ARGUMENTS chains, they are valid arguments
> > that just some
> > invalid code doesn't pass. By removing them you basically always create an
> > invalid case, this time in the other direction, valid
On Tue, Mar 12, 2024 at 08:03:52PM +0100, Simon Chopin wrote:
> On x86, this compiles into movdqa which segfaults on unaligned access.
>
> This kind of failure has been seen when running against glibc 2.39,
> which incidentally changed the printf implementation to move away from
> alloca() for
On Wed, Apr 03, 2024 at 09:35:07AM +0200, Richard Biener wrote:
> Just in case making the control expression constant to the middle-end
> doesn't scale.
I think we need to evaluate it as constant expression in any case, that is
the only way to determine if it is trivial infinite loop or not.
The
On Wed, 3 Apr 2024, Jakub Jelinek wrote:
> Hi!
>
> r13-990 added optimizations in multiple spots to optimize during
> expansion storing of constant initializers into targets.
> In the load_register_parameters and expand_expr_real_1 cases,
> it checks it has a tree as the source and so knows we
Hi!
r13-990 added optimizations in multiple spots to optimize during
expansion storing of constant initializers into targets.
In the load_register_parameters and expand_expr_real_1 cases,
it checks it has a tree as the source and so knows we are reading
that whole decl's value, so the code is
On Wed, Apr 3, 2024 at 9:25 AM Jakub Jelinek wrote:
>
> Hi!
>
> The following patch attempts to implement P2809R3, which has been voted
> in as a DR.
>
> The middle-end has its behavior documented:
> '-ffinite-loops'
> Assume that a loop with an exit will eventually take the exit and
>
Hi!
The following patch attempts to implement P2809R3, which has been voted
in as a DR.
The middle-end has its behavior documented:
'-ffinite-loops'
Assume that a loop with an exit will eventually take the exit and
not loop indefinitely. This allows the compiler to remove loops
2024-04-03 11:19 Jin Ma wrote:
>
>> gcc/testsuite/ChangeLog:
>>
>> * gcc.target/riscv/bf16_arithmetic.c: New test.
>> * gcc.target/riscv/bf16_call.c: New test.
>> * gcc.target/riscv/bf16_comparison.c: New test.
>> * gcc.target/riscv/bf16_float_libcall_convert.c: New test.
>> *
52 matches
Mail list logo
